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1.  INTRODUCTION 

The  objective  of  Simple  Mail  Transfer  Protocol  (SMTP)  is  to  transfer 
mail  reliably  and  efficiently. 

SMTP  is  independent  of  the  particular  transmission  subsystem  and 
requiros  only  a  reliable  ordered  data  stream  channel.  Appendicos  A. 
B,  C.  and  D  describe  the  use  of  SMTP  with  various  transport  services. 
A  Glossary  provides  the  definitions  of  terms  as  used  in  this 
document. 

An  important  feature  of  SMTP  is  its  capability  to  relay  mail  across 
transport  service  environments.  A  transport  service  provides  an 
interprocess  communication  environment  (XPCE).  An  XPCE  may  cover  one 
network,  several  networks,  or  a  subset  of  a  network.  It  is  important 
to  realize  that  transport  systems  (or  XPCEs)  are  not  one-to-one  with 
networks.  A  process  can  communicate  directly  with  another  process 
through  any  mutually  known  XPCE.  Mail  is  an  application  or  use  of 
interprocess  communication.  Mail  can  be  communicated  between 
processes  in  different  XPCEs  by  relaying  through  a  process  connected 
to  two  (or  more)  XPCEs.  More  specifically,  mail  can  be  relayed 
between  hosts  on  different  transport  systems  by  a  host  on  both 
transport  systems. 
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2.  THE  SMTP  MODEL 

The  SMTP  design  is  based  on  the  following  Model  of  communication:  as 
the  result  of  a  user  mail  request,  the  sender-SMTP  establishes  a 
two-way  transmission  channel  to  a  receiver-SMTP.  The  receiver-SMTP 
may  be  either  the  ultimate  destination  or  an  intermediate.  SMTP 
commands  are  generated  by  the  sender-SMTP  and  sent  to  the 
receiver-SMTP.  SMTP  replies  are  sent  from  the  receiver-SMTP  to  the 
sender-SMTP  in  response  to  the  commands. 

Once  the  transmission  channel  is  estab'ished,  the  SMTP-sender  sends  a 
MAIL  command  indicating  the  sender  of  the  mail.  If  the  SMTP-receiver 
can  accept  mail  it  responds  with  an  OK  reply.  The  SMTP-sender  then 
sends  a  RCPT  command  identifying  a  recipient  of  the  mail.  If  the 
SMTP-receiver  can  accept  mail  for  that  recipient  it  responds  with  an 
-v  OK  reply:  if  not.  it  responds  «yith  a  reply  rejecting  that  recipient 
-.(but  not  the  whole  mail  transaction).  The  SMTP-sender  and 
SMTP-receiver  may  negotiate  several  recipients.  When  the  recipients 
have  been  negotiated  the  SMTP-sender  sends  the  mail  data,  terminating 
with  a  special  sequence,  if  the  SMTP-receiver  successfully  processes 
the  mail  data  it  responds  with  an  OK  reply.  The  dialog  is  purposely 
lock-step,  one-at-a-time. 


|  User  |< — >| 

+ - +  | 

+ - +  j 

|  File  |<~>| 
j System j  j 
+ - +  + 


Sender-SMTP  Receiver-SMTP 

Model  for  SMTP  Use 
Figure  i 


|  SMTP  | 

Sender-  j  Commands/Replies | 

SMTP  |< - >  | 

|  and  Mail  | 


I 

Receiver- | 
, SMTP  | 


|<— > 


File  | 

| System | 

•i - + 


The  SMTP  provides  mechanisms  for  the  transmission  of  mail;  directly 
from  the  sending  user's  host  to  the  receiving  user's  host  when  the 
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two  host  are  connected  to  the  same  transport  service,  or  via  one  or 
more  relay  SMTP-servers  when  the  source  and  destination  hosts  are  not 
connected  to  the  same  transport  service. 

To  be  able  to  provide  the  relay  capability  the  SMTP-server  must  be 
supplied  with  the  name  of  the  ultimate  destination  host  as  well  as 
the  destination  mailbox  name. 

The  argument  to  the  MAIL  command  is  a  reverse-path,  which  specifies 
who  the  mail  is  from.  The  argument  to  the  RCPT  command  is  a 
forward-path,  which  specifies  who  the  mail  is  to.  The  forward-path  , 
is  a  source  route,  while  the  reverse-path  is  a  return  route  (which 
may  be  used  to  return  a  message  to  the  sender  when  an  error  occurs 
with  a  relayed  message) . 

when  the  same  message  Is  sent  to  multiple  recipients  the  SMTP 
encourages  the  transmission  of  only  one  copy  of  the  data  for  all  the 
recipients  at  the  same  destination  host. 

The  mail  commands  and  replies  have  a  rigid  syntax.  Replies  also  have 
a  numeric  code.  In  the  following,  examples  appear  which  use  actual 
commands  and  replies.  The  complete  lists  of  commands  and  replies 
appears  in  Section  4  on  specifications. 

Commands  and  replies  are  not  case  sensitive.  That  is.  a  command  or 
reply  word  may  be  upper  case,  lower  case,  or  any  mixture  of  upper  and 
lower  case.  Note  that  this  is  not  true  of  mailbox  user  names.  For 
some  hosts  the  user  name  is  case  sensitive,  and  SMTP  implementations 
must  take  case  to  preserve  the  case  of  user  names  as  they  appear  in 
mailbox  arguments.  Host  names  are  not  case  sensitive. 

Commands  and  replies  are  composed  of  characters  from  the  ASCII 
character  set  (1].  When  the  transport  service  provides  an  8-bit  byte 
(octet)  transmission  channel,  each  7-bit  character  is  transmitted 
right  Justified  in  an  octet  with  the  high  order  bit  cleared  to  zero. 

when  specifying  the  general  form  of  a  command  or  reply,  an  argument 
(or  special  symbol)  will„be  denoted  by  a  meta-linguistic  variable  (or 
constant),  for  example,  h<string>"  or  "<reverse-path>" .  Here  the 
angle  brackets  indicate  these  are  meta-linguistic  variables. 

However;  some  arguments  use  the  angle  brackets  literally.  For 
example,  an  actual  reverse-path  is  enclosed  in  angle  brackets,  i.e., 

" <John . Smi theusc-isi . ARPA>"  is  an  instance  of  <reverse-path>  (the 
angle  brackets  are  actually  transmitted  in  the  command  or  reply). 
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3.  THE  SMTP  PROCEDURES 

This  section  presents  the  procedures  used  in  SMTP  in  several  parts. 
First  comes  the  basic  mail  procedure  defined  as  a  mail  transaction. 
Following  this  are  descriptions  of  forwarding  mail,  verifying  mailbox 
names  and  expanding  mailing  lists,  sending  to  terminals  instead  of  or 
in  combination  with  mailboxes,  and  the  opening  and  closing  exchanges. 
At  the  end  of  this  section  are  comments  on  relaying,  a  note  on  mail 
domains,  and  a  discussion  of  changing  roles.  Throughout  this  section 
are  examples  of  partial  command  and  reply  sequences,  several  complete 
scenarios  are  presented  in  Appendix  F. 

3.1.  MAIL 

There  are  three  steps  to  SMTP  mail  transactions.  The  transaction 
ia  started  alth  a  »£XL  COiiinu  Which  gives  the  sender 
identification.  A  series  of  one  or  more  RCPT  commands  follows 
giving  the  receiver  information.  Then  a  DATA  command  gives  the 
mail  data.  And  finally,  the  end  of  mail  data  indicator  confirms 
the  transaction. 

The  first  step  in  the  procedure  is  the  MAIL  command.  The 
<reverse-path>  contains  the  source  mailbox. 

MAIL  <SP>  FROM: crevar se-path>  <CRLF> 

This  command  tells  the  $MTP-receiver  that  a  new  mail 
transaction  is  starting  and  to  reset  all  its  state  tables  and 
buffers,  including  any  recipients  or  mail  data.  It  gives  the 
reverse-path  which  can  be  used  to  report  errors.  If  accepted, 
the  receiver-SMTP  returns  a  2S0  OK  reply. 

The  <reverse-path>  can  contain  more  than  Just  a  mailbox.  The 
<rever8e-path>  is  a  reverse  source  routing  list  of  hosts  and 
source  mailbox.  The  first  host  in  the  <reverse-path>  should  be 
the  host  sending  this  command. 

The  se  ;ond  step  in  the  procedure  is  the  RCPT  command. 

RCPT  <SP>  TO: <forward-path>  <CRLF> 

This  command  gives  a  forward-path  identifying  one  recipient. 

If  accepted,  the  raceiver-SMTP  returns  a  250  OK  reply,  and 
stores  the  forward-path.  If  the  recipient  is  unknown  the 
receiver-SMTP  returns  a  550  Failure  reply.  This  second  step  of 
the  procedure  can  be  repeated  any  number  of  times. 
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The  <forward-path>  can  contain  more  than  just  a  mailbox.  The 
<forward-path>  is  a  source  routing  list  of  hosts  and  the 
destination  mailbox.  The  first  host  in  the  <forward-path> 
should  be  the  host  receiving  this  command. 

The  third  step  in  the  procedure  is  the  DATA  command. 

DATA  <CRCF> 

if  accepted,  the  receiver-SMTP  returns  a  354  Intermediate  reply 
and  considers  all  succeeding  lines  to  be  the  message  text, 
when  the  end  of  text  is  received  and  stored  the  SMTP-receiver 
sends  a  250  ok  reply. 

Since  the  mail  data  is  sent  on  the  transmission  channel  the  end 
of  the  mail  data  must  be  indie  ited  so  that  the  command  and 
reply  dialog  can  be  resumed.  »MTP  indicates  the  end  of  the 
mail  data  by  sending  a  line  containing  only  a  period.  A 
transparency  procedure  is  used  to  prevent  this  from  interfering 
with  the  user's  text  (see  Section  4.5.2). 

Please  note  that  the  mall  data  includes  the  memo  header 
items  such  as  Date,  Subject.  To,  Cc,  From  [ 2 J . 

The  end  of  mail  data  indicator  also  confirms  the  mail 
transaction  and  tells  the  rec«  .ver-SMTP  to  now  process  the 
stored  recipients  and  mail  da.  w  If  accepted,  the 
receiver--3MTP  returns  a  250  OK  reply.  The  DATA  command  should 
fail  only  if  the  mail  transaction  was  incomplete  (for  example, 
no  recipients),  or  if  resources  are  not  available. 

The  above  procedure  is  an  example  of  a  mail  transaction.  These 
commands  must  be  used  only  in  the  order  discussed  above. 

Example  1  (below)  illustrates  the  use  of  these  commands  in  a  mail 
transaction . 
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Example  of  the  SMTP  Procedure 

This  SMTP  example  shows  mail  sent  by  Smith  at  host  Alpha. arpa, 
to  Jones.  Green,  and  Brown  at  host  Beta. ARPA.  Here  we  assume 
that  host  Alpha  contacts  host  Beta  directly. 

S:  MAIL  FROM: <Smith8Alpha. ARPA> 

R:  250  OK 

S:  RCPT  TO : < JonesOBe t a . ARP A> 

R:  250  OK 

S:  RCPT  TO:<GreenOBeta.ARPA> 

R:  550  No  such  user  here 

S:  RCPT  TO: <BrownOBeta. ARPA> 

R:  250  OK 

S:  DATA 

R:  354  Start  mail  input;  end  with  <CRLF>. <CRLF> 

S:  Blah  blah  blah. . . 

S:  ...etc.  etc.  etc. 

S:  <CRLF> . <CRLF- 
R:  250  OK 

The  mail  has  now  been  accepte  -  for  Jones  and  Brown.  Green  did 
not  have  a  mailbox  at  host  Bei i. 

Example  i 
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3.2.  FORWARDING 

Thera  are  some  cases  where  the  destination  Information  in  the 
<forward-path>  Is  incorrect,  but  the  receiver-SMTP  knows  the 
. correct  destination,  in  a*.—**  cases,  one  of  the  following  replies 
should  be  used  to  allow  the  sender  to  contact  the  correct 
destination. 

251  user  not  local;  will  forward  to  <forward-path> 

This  reply  indicates  that  the  receiver-SMTP  knows  tho  user's 
mailbox  is  on  another  host  and  indicates  the  correct 
forward-path  to  use  in  the  future.  Note  that  either  the 
host  or  user  or  both  may  be  different.  The  receiver  takes 
responsibility  for  delivering  the  message. 

551  user  not  local;  please  try  <forward-path> 

This  reply  indicates  that  the  receiver-SMTP  knows  the  user's 
mailbox  is  on  another  host  and  indicates  the  correct 
forward-path  to  use.  Note  that  either  the  host  or  user  or 
both  may  be  different.  The  receiver  refuses  to  accept  mail 
for  this  user,  and  the  sender  must  either  redirect  the  mail 
according  to  the  information  provided  or  return  an  error 
response  to  the  originating  user. 

Example  2  illustrates  the  use  of  these  responses. 


Example  of  Forwarding 

Either 

S:  RCPT  TO: <Postel9USC-ISI . ARPA> 

R:  251  User  not  local;  will  forward  to  <Postel0USC-ISIF . ARPA> 
Or 


S:  RCPT  TO: <Paul9USC— ISIB . ARPA> 

R:  551  user  not  local;  please  try  <Mockapetr iseuSC-ISIF . ARPA> 

Example  2 
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3.3.  VERZFYZNQ  AND  EXPANOZNC 

SMTP  provides  as  additional  features,  commands  to  verify  a  user 
name  or  expand  a  mailing  list.  This  is  done  with  the  VRFY  and 
EXPN  command.*.-  vhich  have  character  string  arguments.  For  the 
VRFY  command,  the  string  is  a  user  name,  and  the  response  may 
include  the  fu '.1  name  of  the  user  and  must  include  the  mailbox  of 
the  user.  For  the  EXPN  command;  the  string  identifies  a  mailing 
list,  and  the  multiline  response  may  include  the  full  name  of  the 
users  and  must  give  the  mailboxes  on  the  mailing  list. 

"user  name"  is  a  fuzzy  term  and  used  purposely.  Zf  a  host 
implements  the  VRFY  or  EXPN  commands  then  at  least  local  mailboxes 
must  be  recognized  as  "user  names”.  Zf  a  host  chooses  to 
recognize  other  strings  as  "user  names"  that  is  allowed. 

Zn  some  hosts  the  distinction  between  a  mailing  list  and  an  alias 
for  a  single  mailbox  is  a  bit  fuzzy,  since  a  common  data  structure 
may  hold  both  types  of  entries,  and  it  is  possible  to  have  mailing 
lists  of  one  mailbox.  Zf  a  request  is  made  to  verify  a  mailing 
list  a  positive  response  can  be  given  if  on  receipt  of  a  message 
so  addressed  it  will  be  delivered  to  everyone  on  the  list, 
otherwise  an  error  should  be  reported  (e.g..  ”650  That  is  a 
mailing  list,  not  a  user”}.  Zf  a  request  is  made  to  expand  a  user 
name  a  positive  response  can  be  formed  by  returning  a  list 
containing  one  name,  or  an  error  can  be  reported  (e.g.,  ”550  That 
is  a  user  name,  not  a  mailing  list”). 

in  the  case  of  a  multiline  reply  (normal  for  EXPN)  exactly  one 
mailbox  is  to  be  specified  on  eaoh  line  of  the  reply,  zn  the  case 
of  an  ambiguous  request,  for  example,  "VRFY  Smith”,  where  there 
are  two  Smith's  the  response  must  be  ”553  User  ambiguous”. 

The  case  of  verifying  a  user  name  is  straightforward  as  shown  in 
example  3. 
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Example  of  verifying  a  user  Name 

Either 

Ss  VRFY  Smith 

R:  250  Fred  Smith  <Smith8USC— ZSIF . ARPA> 

Or 

S:  VRFY  Smith 

R:  251  User  not  local;  will  forward  to  <SmithOUSC— ZSIQ. ARPA> 
Or 

S:  VRFY  Jones 

R:  550  String  does  not  match  anything. 

Or 

S:  VRFY  Jones 

R:  551  User  net  local;  please  try  <JonesOUSC-zsiQ. Arpa> 

Or 

S:  VRFY  Qourzenkyinplatz 
R:  553  User  ambiguous. 

Example  3 


Postel 


[Page  9] 


August  1982 

Simple  Mail  Transfer  Protocol 


RPC  821 


The  case  of  expanding  a  mailbox  list  requires  a  multiline  reply  as 
shown  in  example  4. 


Example  of  Expanding  a  Mailing  List 


Either 

S:  EXPN  Example-People 

R:  260-Jon  Postel  <Postel«USC-ISZF. ARPA> 

R:  250-Fred  Fonebcne  <Fonebone8USC-ISIQ. ARPA> 

R:  250-Sam  Q.  Smith  <SQSmith#USC-ISlC. ARPA> 

R:  250— Quincy  Smith  <0USC— XSXF . ARPA:Q— SmithOXSX— VAXA. ARPA> 
R:  250-<joe0foo-unix.ARPA> 

R:  250  <xyzObar— unix . ARPA> 


S:  EXPN  Executive-washroom-List 
R:  550  Access  Denied  to  You. 

Example  4 


The  character  string  arguments  of  the  VRFY  and  EXPN  commands 
cannot  be  further  restricted  due  to  the  variety  of  implementations 
of  the  user  name  and  mailbox  list  concepts.  On  some  systems  it 
may  be  appropriate  for  the  argument  of  the  EXPN  command  to  be  a 
file  name  for  a  file  containing  a  mailing  list,  but  again  there  is 
a  variety  of  file  naming  conventions  in  the  Internet. 

The  VRFY  and  EXPN  commands  are  not  included  in  the  minimum 
implementation  (Section  4.5.1).  and  are  not  required  to  work 
across  relays  when  they  are  implemented. 
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3.4.  SENDING  AND  MAILING 


The  main  purpose  of  SMTP  Is  to  deliver  messages  to  user's 
mailboxes.  A  very  similar  service  provided  by  some  hosts  is  to 
deliver  messages  to  user's  terminals  (provided  the  user  is  active 
on  the  ho.fc).  The  delivery  to  the  user's  mailbox  is  called 
"mailing”,  the  delivery  to  the  user's  terminal  is  called 
"sending".  Because  in  many  hosts  the  implementation  of  sending  is 
nearly  identical  to  the  implementation  of  mailing  these  two 
functions  are  combined  in  SMTP.  However  the  sending  commands  are 
not  included  in  the  required  minimum  implementation 
(Section  4.S.1).  Users  should  have  the  ability  to  control  the 
writing  of  messages  on  their  terminals.  Most  hosts  permit  the 
users  to  accept  or  refuse  such  messages. 

The  following  three  command  are  defined  to  support  the  sanding 
options.  These  are  used  in  the  mail  transaction  instead  of  the 
MAIL  command  and  inform  the  receiver-SMTP  of  the  special  semantics 
of  this  transaction: 

SEND  <SP>  FROM:<reverse-path>  <CRLF> 


The  SEND  command  requires  that  the  mail  data  be  delivered  to 
the  user's  terminal,  if  the  user  is  not  active  (or  not 
accepting  terminal  messages)  on  the  host  a  450  reply  may 
returned  to  a  RCPT  command.  The  mail  transaction  is 
successful  if  the  message  is  delivered  the  terminal. 

SOML  <SP>  FROM:<reverse-path>  <CRLF> 


The  Send  Or  MaiL  command  requires  that  the  mail  data  be 
delivered  to  the  iser's  terminal  if  the  user  is  active  (ard 
accepting  terminal  messages)  on  the  host.  If  the  user  is 
not  active  (or  not  accepting  terminal  messages)  then  the 
mail  data  is  entered  into  the  user's  mailbox.  The  mail 
transaction  is  successful  if  the  message  is  delivered  either 
to  the  terminal  or  the  mailbox. 


SAML  <SP>  FROM: <reverse-path>  <CRLF> 


The  Send  And  MaiL  command  requires  that  the  mail  data  be 
delivered  to  the  user's  terminal  if  the  user  is  active  (an 
accepting  terminal  messages)  on  the  host,  in  any  case  the 
mail  data  is  entered  into  the  user's  mailbox.  The  mail 
transaction  is  successful  if  the  message  is  delivered  the 
mailbox . 
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Tha  same  reply  codes  that  are  used  for  the  MAIL  commands  are  used 
for  these  commands. 
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3.5.  OPENING  ANO  CLOSING 

At  the  time  the  transmission  channel  is  opened  there  is  an 
exchange  to  ensure  that  the  hosts  are  communicating  with  the  hosts 
they  think  they  are. 

The  following  two  commands  are  used  in  transmission  channel 
opening  and  closing: 

HELO  <SP>  <domain>  <CRLF> 

QUIT  <CRLF> 

in  the  HELO  command  the  host  sending  the  command  identifies 
itself:  the  command  may  be  interpreted  as  saying  ’Hello.  I  am 
<domain>". 


Example  of  Connection  Opening 

R:  220  BBN— UNIX. ARPA  Simple  Mail  Transfer  Service  Ready 
S:  HELO  USC— ISIF. ARPA 
R:  250  BBN— UNIX . ARPA 


Example  5 


Example  of  Connection  Closing 

S:  QUIT 

R:  221  bbn-unix. ARPA  Service  closing  transmission  channel 

Example  6 
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3.6.  RELAYING 

The  forward-path  may  be  a  source  route  of  the  form 
"OONE.OTWO: joeothree*.  where  ONE.  TWO,  and  three  are  hosts.  This 
form  is  used  to  emphasize  the  distinction  between  an  address  and  a 
route.  The  mailbox  is  an  absolute  address,  and  the  route  is 
information  about  how  to  get  there.  The  two  concepts  should  not 
be  confused. 

Conceptually  the  elements  of  the  forward-path  are  moved  to  the 
reverse-path  as  the  message  is  relayed  from  one  server-SMTP  to 
another.  The  reverse-path  is  a  reverse  source  route,  (i.e.,  a 
source  route  from  the  current  location  of  the  message  to  the 
originator  of  the  message),  when  a  server-SMTP  deletes  its 
identifier  from  the  forward-path,  and  inserts  it  into  the 
reverse-path,  it  must  use  the  name  it  is  known  by  in  the 
environment  it  is  sending  into,  not  the  environment  the  mail  came 
from,  in  case  the  server-SMTP  is  known  by  different  names  in 
different  environments. 

If  when  the  message  arrives  at  an  SMTP  the  first  element  of  the 
forward-path  is  not  the  identifier  of  that  SMTP  the  element  is  not 
deleted  from  the  forward-path  and  is  used  to  determine  the  next 
SMTP  to  send  the  message  to.  in  any  case,  the  SMTP  adds  its  own 
identifier  to  the  reverse-path. 

using  source  routing  the  receiver-SMTP  receives  mail  to  be  relayed 
to  another  server-SMTP  The  receiver-SMTP  may  accept  or  reject  the 
task  of  relaying  the  mail  in  the  same  way  it  accepts  or  rejects 
mail  for  a  local  user.  The  receiver-SMTP  transforms  the  command 
arguments  by  moving  its  own  identifier  from  the  forward-path  to 
the  beginning  of  the  reverse-path.  The  receiver-SMTP  then  becomes 
a  sender-SMTP,  establishes  a  transmission  channel  to  the  next  SMTP 
in  the  forward-path,  and  sends  it  the  mail. 

The  first  host  in  the  reverse-path  should  be  the  host  sending  the 
SMTP  commands,  and  the  first  host  in  the  forward-path  should  be 
the  host  receiving  the  SMTP  commands. 

Notice  that  the  forward-path  and  reverse-path  appear  in  the  SMTP 
commands  and  replies,  but  not  necessarily  in  the  message.  That 
is,  there  is  no  need  for  these  paths  and  especially  this  syntax  to 
appear  in  the  "To:"  ,  "From:",  "CC:",  etc.  fields  of  the  message 
header . 

if  a  server-SMTP  has  accepted  the  task  of  relaying  the  mail  and 
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lator  finds  that  the  forward-path  is  Incorract  or  that  tha  nail 
cannot  bo  delivered  for  whatever  reason,  then  it  aust  construct  an 
"undeliverable  nail"  notification  message  and  send  it  to  the 
originator  of  the  undeliverable  mail  (as  indicated  by  the 
reverse-path) . 

This  notification  message  must  be  from  the  server-SMTP  at.  this 
host.  Of  course,  server-SMTPs  should  not  send  notification 
messages  about  problems  with  notification  messages.  One  way  to 
prevent  loops  in  error  reporting  is  to  specify  a  null  reverse-path 
in  the  mail  command  of  a  notification  message.  When  such  a 
message  is  relayed  it  is  permissible  to  leave  the  reverse-path 
null.  A  mail  command  with  a  null  reverse-path  appeara  as  follows: 

MAIL  FROM: <> 

An  undeliverable  mail  notification  message  is  shown  in  example  7. 
This  notification  is  in  response  to  a  message  originated  by  JOE  at 
HOSTW  and  sent  via  HOSTX  to  HOSTY  with  instructions  to  relay  it  on 
to  HOSTZ.  what  we  see  in  the  example  is  the  transaction  between 
HOSTY  and  H03TX,  which  is  the  first  step  in  the  return  of  the 
notification  message. 
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Example  undeliverable  Mall  Notification  Message 


s 

R 

S 

R 

S 

R 

S 

S 

S 

s 

s 

s 

s 

s 

s 

R 


MAIL  FROM: <> 

250  ok 

RCPT  TO : <OHOSTX . ARPA : JOEOHOSTW . ARPA> 

250  ok 
DATA 

354  send  the  mail  data,  end  with  . 

Date:  23  Oct  81  11:22*33 
From:  SMTPOHOSTY . ARP/i 
To:  JOEOHOSTW. ARPA 
Subject:  Mail  System  Problem 

Sorry  JOE,  your  message  to  SAM0H0ST2. ARPA  lost. 
HOSTZ . ARPA  said  this: 

”550  No  Such  user" 

250  ok 


Example  7 
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3.7.  DOMAINS 

Domains  are  a  recently  introduced  concept  in  the  ARPA  internet 
mail  system.  The  use  of  domains  changes  the  address  space  from  a 
flat  global  space  of  simple  character  string  host  names  to  a 
hierarchically  structured  rooted  tree  of  global  addresses.  The 
host  name  is  replaced  by  a  domain  and  host  designator  which  is  a 
sequence  of  domain  element  strings  separated  by  periods  with  the 
understanding  that  the  domain  elements  are  ordered  from  the  most 
specific  to  the  most  general. 

For  example,  "USC-ISIF. ARPA",  "Fred. Cambridge. UK",  and 
"PC7. LCS. MIT. ARPA"  might  be  host-and-domain  identifiers. 

Whenever  domain  names  are  used  in  SMTP  only  the  official  names  are 
used,  the  use  of  nicknames  or  aliases  is  not  allowed. 
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3.8.  CHANGING  ROLES 

The  TURN  command  may  be  used  to  reverse  the  roles  of  the  two 
programs  communicating  over  the  transmission  cnannel. 

if  program-A  is  currently  the  sender-SMTP  and  it  sends  the  TURN 
command  and  receives  an  ok  reply  (250)  then  program-A  becomes  the 
receiver-SMTP. 

If  program-B  is  currently  the  receiver-SMTP  and  it  receives  the 
TURN  command  and  sends  an  ok  reply  (250)  then  program-B  becomes 
the  sender-SMTP. 

To  refuse  to  change  roles  the  receiver  sends  the  502  reply. 

Please  note  that  this  command  is  optional.  It  would  not  normally 
be  used  in  situations  where  the  transmission  channel  is  TCP. 
However,  when  the  cost  of  establishing  the  transmission  channel  is 
high,  this  command  may  be  quite  useful.  For  example,  this  command 
may  be  useful  in  supporting  bn  mail  exchange  using  the  public 
switched  telephone  system  as  a  transmission  channel,  especially  if 
some  hosts  poll  other  hosts  for  mall  exchanges. 
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4.  THE  SMTP  SPECIFICATIONS 
4.1.  SMTP  COMMANDS 

4.1.1.  COMMAND  SEMANTICS 

The  SMTP  commands  define  the  mail  transfer  or  the  mail  system 
function  requested  by  the  user.  SMTP  commands  are  character 
strings  terminated  by  <CRLF>.  The  command  codes  themselves  are 
alphabetic  characters  terminated  by  <SP>  if  paramoters  follow 
and  <CRLF>  otherwise.  The  syntax  of  mailboxes  must  conform  to 
receiver  site  conventions.  The  SMTP  commands  are  discussed 
below.  The  SMTP  replies  are  discussed  in  the  section  4.2. 


A  mail  transaction  involves  several  data  objects  which  are 
communicated  as  arguments  to  different  commands.  The 
reverse-path  is  tne  argument  of  the  MAIL  command,  the 
forward-path  is  the  argument  of  the  RCPT  command,  and  the  mail 
data  is  the  argument  of  the  DATA  command.  These  arguments  or 
de£a  objects  must  be  transmitted  and  held  pending  the 
confirmation  communicated  by  the  end  of  mail  data  indication 
which  finalizes  the  transaction.  The  model  for  this  is  that 


distinct  buffers  are  provided  to  hold  the  types  of  data 
objects,  that  is,  there  is  a  reverse-path  buffer,  a 
forward-path  buffer,  and  a  mail  data  buffer.  Specific  commands 
cause  information  to  be  appended  to  a  specific  buffer,  or  cause 
one  or  more  buffers  to  be  cleared. 


HELLO  (HELO) 


This  command  is  used  to  identify  the  sender-SMTP  to  the 
receiver-SMTP.  The  argument  field  contains  the  host  name  of 
the  sendei — SMTP. 


The  receiver-SMTP  identifies  itself  to  the  sender-SMTP  in 
the  connection  greeting  reply,  and  in  the  response  to  this 
command. 


This  command  and  an  OK  reply  to  it  confirm  that  both  the 
sendei — SMTP  and  the  receiver-SMTP  are  in  the  initial  state, 
that  is,  there  is  no  transaction  in  progress  and  all  state 
tables  and  buffers  are  cleared. 
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MAIL  (MAIL) 

This  command  is  used  to  initiate  a  mail  transaction  in  which 
the  mail  data  is  delivered  to  one  or  more  mailboxes.  The 
argument  field  contains  a  reverse-path. 

The  reverse-path  consists  of  an  optional  list  of  hosts  and 
the  sender  mailbox.  When  the  list  of  hosts  is  present,  it 
is  a  "reverse”  source  route  and  indicates  that  the  mail  was 
relayed  through  each  host  on  the  list  (the  first  host  in  the 
list  was  the  most  recent  relay).  This  list  is  used  as  a 
source  route  to  return  non-delivery  notices  to  the  sender. 

As  each  relay  host  adds  itself  to  the  beginning  of  the  list, 
it  must  use  its  name  as  known  in  the  IPCE  to  which  it  is 
relaying  the  mail  rather  than  the  IPCE  from  which  the  mail 
came  (if  they  are  different).  In  some  types  of  error 
reporting  messages  (for  example,  undeliverable  mail 
notifications)  the  reverse-path  may  be  null  (see  Example  7). 

This  command  clears  the  reverse-path  buffer,  the 
forward-path  buffer,  and  the  mail  data  buffer;  and  inserts 
the  reverse-path  information  from  this  command  into  the 
reverse-path  buffer. 

RECIPIENT  (RCPT) 

This  command  is  used  to  idjntify  an  individual  recipient  of 
the  mail  data;  multiple  recipients  are  specified  by  multiple 
use  of  this  command. 

The  forward-path  consists  of  an  optional  list  of  hosts  and  a 
required  destination  mailbox.  When  the  list  of  hosts  is 
present,  it  is  a  source  route  and  indicates  that  the  mail 
must  be  relayed  to  the  next  host  on  the  list.  If  the 
receiver-SMTP  does  not  implement  the  relay  function  it  may 
user  the  same  reply  it  would  for  an  unknown  local  user 
(550) . 

When  mail  is  relayed,  the  relay  host  must  remove  itself  from 
the  beginning  forward-path  and  put  itself  at  the  beginning 
of  the  reverse-path,  when  mail  reaches  its  ultimate 
destination  (the  forward-path  contains  only  a  destination 
mailbox),  the  receiver-SMTP  inserts  it  into  the  destination 
mailbox  it;  accordance  with  its  host  mail  conventions. 
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For  example,  mall  received  at  relay  host  A  with  arguments 
FROM : <USERXOHOST Y . ARPA> 

TO : <OHOSTA . ARPA . OHOSTB . ARPA : USERCBHOSTD . ARP A> 

will  be  relayed  on  to  host  B  with  arguments 

FROM: <OHOSTA . ARPA : USERXOHOSTY . ARPA> 

TO: <«HOSTB . ARPA : USERCOHOSTD . ARPA> . 

This  command  causes  its  forward-path  argument  to  be  Appended 
to  the  forward-path  buffer. 

DATA  (DATA) 

The  receiver  treats  the  lines  following  the  command  as  mail 
data  from  the  sender.  This  command  causes  the  mail  data 
from  this  command  to  be  appended  to  the  mail  data  buffer. 

The  mail  data  may  contain  any  of  the  128  ASCII  character 
codes. 

The  mail  data  is  terminated  by  a  line  containing  only  a 
period,  that  is  the  character  sequence  "<CRLF>.<CRLF>"  (see 
Section  4.5.2  on  Transparency).  This  is  the  end  of  mail 
data  indication. 

The  end  of  mail  data  indication  requires  that  the  receiver 
must  now  process  the  stored  mail  transaction  information. 
This  processing  consumes  tho  information  in  the  reverse-path 
buffer,  the  forward-path  buffer,  and  the  mail  data  buffer, 
and  on  the  completion  of  this  command  these  buffers  are 
cleared.  If  the  processing  is  successful  the  receiver  must 
send  an  OK  reply.  If  the  processing  fails  completely  the 
receiver  must  send  a  fMlure  reply. 

when  the  receiver-SKTP  accepts  a  message  either  for  relaying 
or  for  final  delivery  it  inserts  at  the  oeginning  of  the 
mail  data  a  time  stamp  line.  The  time  stamp  line  indicates 
the  identity  of  the  host  that  sent  the  message,  and  the 
identity  of  the  host  that  received  the  message  (and  is 
ins'vv'i.ig  this  time  stamp),  and  the  date  and  time  the 
mes/  '' n  was  received.  Relayed  messages  will  have  multiple 
tiir.  .tamp  lines. 

When  the  receiver-SMTP  makes  the  "final  delivery"  of  a 
message  it  inserts  at  the  beginning  of  the  mail  data  a 
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return  path  line.  The  return  path  line  preserves  the 
information  in  the  <reverse-path>  from  the  MAIL,  command. 
Here,  final  delivery  means  the  message  leaves  the  SMTP 
world.  Normally,  this  would  mean  it  has  been  delivered  to 
the  destination  user,  but  in  some  cases  it  may  be  further 
processed  and  transmitted  by  another  mail  system. 

Zt  is  possible  for  the  mailbox  in  the  return  path  be 
different  from  the  actual  sender's  mailbox,  for  example, 
if  error  responses  are  to  be  delivered  a  special  error 
handling  mailbox  rather  than  the  message  senders. 

The  preceding  two  paragraphs  imply  that  the  final  mail  data 
will  begin  with  a  return  path  line,  followed  by  one  or  more 
time  stamp  lines.  These  lines  will  be  followed  by  the  mail 
data  header  and  body  [2].  See  Example  8. 

Special  mention  is  needed  of  the  response  and  further  action 
required  when  the  processing  following  the  end  of  mail  data 
indication  is  partially  successful.  This  could  arise  if 
after  accepting  several  recipients  and  the  mail  data,  the 
receiver-SMTP  finds  that  the  mail  data  can  be  successfully 
delivered  to  some  of  the  recipients,  but  it  cannot  be  to 
others  (for  example,  due  to  mailbox  space  allocation 
problems).  In  such  a  situation,  the  response  to  the  DATA 
command  must  be  an  OK  reply.  But,  the  receiver-SMTP  must 
compose  and  send  an  "undeliverable  mail"  notification 
message  to  the  originator  of  the  message.  Either  a  single 
notification  which  lists  all  of  the  recipients  that  failed 
to  get  the  message,  or  separate  notification  messages  must 
be  sent  for  each  failed  recipient  (see  Example  7).  All 
undeliverable  mail  notification  messages  are  sent  using  the 
MAIL  command  (even  if  they  result  from  processing  a  SEND, 
SOML ,  or  SAML  command). 
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Example  of  Return  Path  and  Received  Time  Stamps 

Return-Path:  <®GHI . ARPA , ODE F . ARP A , OABC . ARPA : JOEOABC . ARPA> 
Received:  from  GHZ. ARPA  by  JKL.ARPA  ;  27  Oct  81  15:27:39  PST 

Received:  from  OEF.ARPA  by  GHZ. ARPA  ;  27  Oct  81  15:15:13  PST 

Received:  from  ABC. ARPA  by  OEF.ARPA  ;  27  Oct  81  15:01:59  PST 

Date:  27  Oct  81  15:01:01  PST 
From:  JOEOABC. ARPA 

Subject:  Improved  Mailing  System  installed 
To:  SAM4JKL . ARPA 

This  is  to  inform  you  that  ... 

Example  8 


SEND  (SEND) 

This  command  is  used  to  initiate  a  mail  transaction  in  which 
the  mail  data  is  delivered  to  one  or  more  terminals.  The 
argument  field  contains  a  reverse-path.  This  command  is 
successful  if  the  message  is  delivered  to  a  terminal. 

The  reverse-path  consists  of  an  optional  list  of  hosts  and 
the  sender  mailbox.  When  the  list  of  hosts  is  present,  it 
is  a  'reverse”  source  route  and  indicates  that  the  mail  was 
relayed  through  each  host  on  the  list  (the  first  host  in  the 
list  was  the  most  recent  relay).  This  list  is  used  as  a 
source  route  to  return  non-delivery  notices  to  the  sender. 

As  each  relay  host  adds  itself  to  the  beginning  of  the  list, 
it  must  use  its  name  as  known  in  the  ZPCE  to  which  it  is 
relaying  the  mail  rather  than  the  ZPCE  from  which  the  mail 
came  (if  they  are  different). 

This  command  clears  the  reverse-path  buffer,  the 
forward-path  buffer,  and  the  mail  data  buffer;  and  inserts 
the  reverse-path  information  from  this  command  into  the 
reverse-path  buffer. 

SEND  OR  MAZL  (SOML) 

This  command  is  used  to  initiate  a  mail  transaction  in  which 
the  mail  data  Is  delivered  to  one  or  more  terminals  or 


tel 


Pos 
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mailbr <es.  For  each  recipient  the  mail  data  is  delivered  to 
the  r< c.ipient's  terminal  if  the  recipient  is  active  on  the 
host  (find  accepting  terminal  messages),  otherwise  to  the 
recipient's  mailbox.  The  argument  field  contains  a 
reverse-path.  This  command  is  successful  if  the  message  is 
delivered  to  a  terminal  or  the  mailbox. 

The  reverse-path  consists  of  an  optional  list  of  hosts  and 
the  sender  mailbox.  When  the  list  of  hosts  is  present,  it 
is  a  "reverse”  source  route  and  indicates  that  the  mail  was 
relayed  through  each  host  on  the  list  (the  first  host  in  the 
list  was  the  most  recent  relay).  This  list  is  used  as  a 
source  route  to  return  non-delivery  notices  to  the  sender. 

As  each  relay  host  adds  itself  to  the  beginning  of  the  list, 
it  must  use  its  name  as  known  in  the  IPCE  to  which  it  is 
relaying  the  mail  rather  than  the  IPCE  from  which  the  mail 
came  (if  they  are  different). 

This  command  clears  the  reverse-path  buffer,  the 
forward-path  buffer,  and  the  mail  data  buffer;  and  inserts 
the  reverse-path  information  from  this  command  into  the 
reverse-path  buffer. 

SEND  AND  MAIL  (SAML) 

This  command  is  used  to  initiate  a  mail  transaction  in  which 
the  mail  data  is  delivered  to  one  or  more  terminals  and 
mailboxes.  For  each  recipient  the  mail  data  is  delivered  to 
the  recipient's  terminal  if  the  recipient  is  active  on  the 
host  (and  accepting  terminal  messages),  and  for  all 
recipients  to  the  recipient's  mailbox.  The  argument  field 
contains  a  reverse-path.  This  command  is  successful  if  the 
message  is  delivered  to  the  mailbox. 

The  reverse-path  consists  of  an  optional  list  of  hosts  and 
the  sender  mailbox.  When  the  list  of  hosts  is  present,  it 
is  a  "reverse"  source  route  and  indicates  that  the  mail  was 
relayed  through  each  host  on  the  list  (the  first  host  in  the 
list  was  the  most  recent  relay).  This  list  is  used  as  a 
source  route  to  return  non-delivery  notices  to  the  sender. 

As  each  relay  host  adds  itself  to  the  beginning  of  the  list, 
it  must  use  its  name  ts  known  in  the  IPCE  to  which  it  is 
relaying  the  mall  rather  than  the  IPCE  from  which  the  mail 
came  (if  thty  are  different). 

This  command  clears  the  reverse-path  buffer,  the 
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forward-path  buffer,  and  the  mail  data  buffer;  and  inserts 
the  reverse-path  information  from  this  command  into  the 
reverse-path  buffer. 

RESET  (RSET) 

This  command  specifies  that  the  current  mail  transaction  is 
to  be  aborted.  Any  stored  sender,  recipients,  and  mail  data 
must  be  discarded,  and  all  buffers  and  state  tables  cleared. 
The  receiver  must  send  an  OK  reply, 

VERIFY  (VRFY) 

This  command  asks  the  receiver  to  confirm  that  the  argument 
identifies  a  user,  if  it  is  a  user  name,  the  full  name  of 
the  user  (if  known)  and  the  fully  specified  mailbox  are 
returned. 

This  command  has  no  effect  on  any  of  the  reverse-path 
buffer,  the  forward-path  buffer,  or  the  mail  data  buffer. 

EXPANO  ( EXPN ) 

This  command  asks  the  receiver  to  confirm  that  the  argument 
identifies  a  mailing  list,  and  if  so,  to  return  the 
membership  of  that  list.  The  full  name  of  the  users  (if 
known)  and  the  fully  specified  mailboxes  are  returned  in  a 
multiline  reply. 

This  command  has  no  effect  on  any  of  the  reverse-path 
buffer,  the  forward-path  buffer,  or  the  mail  data  buffer. 

HELP  (HELP) 

This  command  causes  the  receiver  to  send  helpful  information 
to  the  sender  of  the  HELP  command.  The  command  may  take  an 
argument  (e.g.,  any  command  name)  and  return  more  specific 
information  as  a  response. 

This  command  has  no  effect  on  any  of  the  reverse-path 
buffer,  the  forward-path  buffer,  or  the  mail  data  buffer. 
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NOOP  (NOOP) 

This  command  does  not  affect  any  parameters  or  previously 
entered  commands.  It  specifies  no  action  other  than  that 
the  receiver  send  an  OX  reply. 

This  command  has  no  effect  on  any  of  the  reverse-path 
buffer,  the  forward-path  buffer,  or  the  mail  data  buffer. 

QUIT  (QUIT) 

This  command  specifies  that  the  receiver  must  send  an  ok 
reply,  and  then  close  the  transmission  channel. 

The  receiver  should  not  close  the  transmission  channel  until 
it  receives  and  replies  to  a  QUIT  command  (even  if  there  was 
an  error).  The  sender  should  not  close  the  transmission 
channel  until  it  send  a  QUIT  command  and  receives  the  reply 
(even  if  there  was  an  error  response  to  a  previous  command) . 
If  the  connection  is  closed  prematurely  the  receiver  should 
act  as  if  a  RSET  command  had  been  received  (canceling  any 
pending  transact. ion,  but  not  undoing  any  previously 
completed  transaction) .  the  senoer  should  act  as  if  the 
command  or  transaction  in  progress  had  received  a  temporary 
error  (4xx). 

TURN  (TURN) 

This  command  specifies  that  the  receiver  must  either  (1) 
send  an  OK  reply  and  then  take  on  the  role  of  the 
sender-SMTP,  or  (2)  send  a  refusal  reply  and  retain  the  role 
of  the  receiver-SMTP. 

If  program-A  is  currently  the  sender-SMTP  and  it  sends  the 
TURN  command  and  receives  an  OK  reply  (250)  then  program-A 
becomes  the  receiver-SMTP.  Program-A  is  then  in  the  initial 
state  as  if  the  transmission  channel  just  opened,  and  it 
then  sends  the  220  service  ready  greeting. 

If  program-B  is  currently  the  receiver-SMTP  and  it  receives 
the  TURN  command  and  sends  an  OK  reply  (250)  then  program-B 
becomes  the  sender-SMTP.  Program-B  is  then  in  the  initial 
state  as  if  the  transmission  channel  just  opened,  and  it 
then  expects  to  receive  the  220  service  ready  greeting. 

To  refuse  to  change  roles  the  receiver  sends  the  502  reply. 
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There  are  restrictions  on  the  order  in  which  these  command  may 
be  used. 

The  first  command  in  a  session  must  be  the  HELO  command. 

The  HELO  command  may  be  used  later  in  a  session  as  well.  Zf 
the  HELO  command  argument  is  not  acceptable  a  501  failure 
reply  must  be  returned  and  the  receiver-SMTP  must  stay  in 
the  same  state. 

The  noop.  help,  expn,  and  VRFY  commands  can  be  used  at  any 
time  during  a  session. 

The  MAIL.  SEND,  SOML.  or  SAML  commands  begin  a  mail 
transaction.  Once  started  a  mail  transaction  consists  of 
one  of  the  transaction  beginning  commands,  one  or  more  RCPT 
commands,  and  a  DATA  command,  in  that  order.  A  mail 
transaction  may  be  aborted  by  the  RSET  command.  There  may 
be  zero  or  more  transactions  in  a  session. 

Zf  the  transaction  beginning  command  argument  is  not 
acceptable  a  501  failure  reply  must  be  returned  and  the 
receiver-SMTP  must  stay  in  the  same  state.  Zf  the  commands 
in  a  transaction  are  out  of  order  a  503  failure  reply  must 
be  returned  and  the  receiver-SMTP  must  stay  in  the  same 
state. 

The  last  command  in  a  session  must  be  the  QUIT  command.  The 
QUZT  command  can  not  be  used  at  any  other  time  in  a  session. 

4.1.2.  COMMAND  SYNTAX 

The  commands  consist  of  a  command  code  followed  by  an  argument 
field.  Command  codes  are  four  alphabetic  characters.  Upper 
and  lower  case  alphabetic  characters  are  to  be  treated 
identically.  Thus,  any  of  the  following  may  represent  the  mail 
command: 

mail  Mail  mail  Mall  mAil 

This  also  applies  to  any  symbols  representing  parameter  values, 
such  as  "TO"  or  "to"  for  the  f orward-path .  Command  codes  and 
the  argument  fields  are  separated  by  one  or  more  spaces. 
However,  within  the  reverse-path  and  forward-path  arguments 
case  is  important.  In  particular,  in  some  hosts  the  user 
"smith"  is  different  from  the  user  "Smith". 
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The  argument  field  consists  of  a  variable  length  character 
string  ending  with  the  character  sequence  <CRLF>.  The  receiver 
is  to  take  no  action  until  this  sequence  is  received. 

Square  brackets  denote  an  optional  argument  field.  If  the 
option  is  not  taken,  the  appropriate  default  is  implied. 
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The  following  are  the  SMTP  commands! 

HELO  <SP>  <domain>  <CP.LF> 

MAIL  <SP>  FROM: <reverse-path>  <CRLF> 

RCPT  <SP>  TO:<forward-path>  <CRLF> 

DATA  <CRLF> 

RSET  <CRLF> 

SEND  <SP>  FROM:<reverse-path>  <crlf> 

S0ml  <SP>  FROM: <r ever se-path>  <CRLF> 
saml  <sp>  from: <reverse-path>  <CRLF> 

VRFY  <SP>  <string>  <CRLF> 

EXPN  <SP>  <string>  <CRLF> 

HELP  [<SP>  <string>]  <CRLF> 

NOOP  <CRLF> 

OUIT  <CRLF> 

TURk’  <CRLF> 


.  r 
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The  syntax  of  th«»  above  argument  fields  (using  BNF  notation 
where  applicable)  is  given  below.  The  notation  indicates 

that  a  field  may  be  repeated  one  or  more  times. 

<reverse-path>  : :«  <path> 

<forw*rd-path>  <path> 

<path>  "<"  [  <a-d-l>  J  <mailbox>  ">* 

<a-d-l>  <at-domain>  |  <at-domain>  "»■  <a-d-l> 

<at-domain>  "O’  <domain> 

<domain>  <element>  |  <element>  <domain> 

<element>  <name>  |  "#•  <number>  |  •(*  <dotnum>  "J* 
<mailbox>  <local-part>  "0"  <domain> 

<local-part>  s:«  <dot-string>  |  <quoted-str ing> 

<name>  <a>  <ldh-str>  <let-dig> 

<ldh-str>  ::»•  <let-dig-hyp>  |  <let-dig~hyp>  <ldh-str> 
<let-dig>  <a>  |  <d> 

<let-dig-hyp>  <a>  |  <d>  | 

<dot-string>  <string>  |  <string>  <dot-string> 

<string>  <char>  |  <char>  <string> 

<quoted-str ing>  s :■  **"  <qtext> 

<qtext>  *\"  <x>  |  "\"  <x>  <qtext>  |  <q>  |  <q>  <qtext> 

<char>  <c>  |  "\"  <x> 

<dotnum>  <snum>  <snum>  <snum>  <snum> 

<number>  <d>  |  <d>  <number> 

<CRLF>  <CR>  <LF> 
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<CR>  the  carriage  return  character  (ASCII  code  13) 
<LF>  the  line  feed  character  (ASCII  code  10) 


<SP>  the  space  character  (ASCII  code  32) 


<snum>  : !»  one,  two,  or  three  digits  representing  a  decimal 
integer  value  in  the  range  0  through  255 


<a> 

<c> 

<d> 

<q> 

<x> 


any  one  of  the  52  alphabetic  characters  A  through  z 
in  upper  case  and  a  through  z  in  lower  case 

any  one  of  the  128  ASCII  characters,  but  not  any 
<special>  or  <SP> 

any  one  of  the  ten  digits  0  through  9 

any  one  of  the  128  ASCII  characters  except  <CR>, 
<LF> ,  quote  ("),  or  backslash  (\) 

any  one  of  the  128  ASCII  characters  (no  exceptions) 


<special> 


"<"  I  «>"  I  «("  I  «)"  I  -[-  I  «]»  I  «\«  I  »." 

|  I  I  ":*  |  "0“  """  |  the  control 

characters  (ASCII  codes  0  through  31  inclusive  ar.d 
127) 


Note  that  the  backslash,  "\",  is  a  quote  character,  which  is 
used  to  indicate  that  the  next  character  is  to  be  used 
literally  (instead  of  its  normal  interpretation).  For  example, 
"Joe\, Smith"  could  be  used  to  indicate  a  single  nine  character 
user  field  with  comma  being  the  fourth  character  of  the  field. 

Hosts  are  generally  known  by  names  which  are  translated  to 
addresses  in  each  host.  Note  that  the  name  elements  of  domains 
are  the  official  names  —  no  use  of  nicknames  or  aliases  is 
allowed. 


Sometimes  a  host  is  not  known  to  the  translation  function  and 
communication  is  blocked.  To  bypass  this  barrier  two  numeric 
forms  are  also  allowed  for  host  "names".  One  form  is  a  decimal 
integer  prefixed  by  a  pound  sign,  "#",  whi^h  indicates  the 
number  is  the  address  of  the  host.  Another  form  is  four  small 
decimal  integers  separated  by  dots  and  enclosed  by  brackets, 
e.g.,  "(123.255.37.2]",  which  indicates  a  32-bit  ARPA  Internet 
Address  in  four  8-blt  fields. 
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The  time  stamp  line  and  the  return  path  line  are  formally 
defined  as  follows: 

<r  ,  :urn-path-line>  "Return-Path:"  <SP><reverse-path><CRLF> 

<time-stamp-line>  ::>■  "Received:"  <SP>  <stamp>  <CRLF> 

<stamp>  ::■  <f rom-domain>  <by-domain>  <opt-info>  ";" 
<daytime> 

<from-domain>  ::■  "FROM"  <SP>  <domain>  <SP> 

<by-domain>  : : ■  "BY"  <SP>  <domatn>  <SP> 

<opt-info>  ::■  [<via>]  [<with>]  £ <id> J  [<for>] 

<via>  ::■  "VIA"  <SP>  <link>  <SP> 

<**ith>  ::*  "WITH"  <SP>  <protocol>  <SP> 

<id>  ::«  "10"  <SP>  <string>  <SP> 

<for>  "FOR"  <SP>  <patn>  <SP> 

<link>  : : »'  The  standard  names  for  links  are  registered  with 
the  Network  information  Center. 

<protocol>  ::-  The  standard  names  for  protocols  are 

registered  with  the  Network  Information  Center. 

<daytime>  ::«  <SP>  <date>  <SP>  <time> 

<Jate>  <dd>  <SP>  <mon>  <SP>  <yy> 

<time>  ::»  <hh>  ":"  <mm>  ":"  <ss>  <SP>  <zone> 

<dd>  ::=»  the  one  or  two  decimal  integer  day  of  the  month  in 
the  range  1  to  31. 

<mon>  ::=  "JAN"  |  "FEB"  |  "MAR"  |  " ATR"  |  "MAY"  |  "JUN"  | 
"JUL"  j  " AUQ"  |  "SEP"  |  "OCT"  |  "NOV"  |  "DEC" 

<yy>  ::*  the  two  decimal  integer  year  of  the  century  in  the 
range  00  to  99. 
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<hh>  the  two  decimal  integer  hour  of  the  day  in  the 
range  00  to  24. 

<mm>  the  two  decimal  integer  minute  of  the  hour  in  the 
range  00  to  59. 

<ss>  the  two  decimal  integer  second  of  the  minute  in  the 
range  00  to  59. 

<zone>  "UT"  for  Universal  Time  (the  default)  or  other 
time  zone  designator  (as  in  (2]). 


Return  Path  Example 

Return-Path :  <®CHARLIG . ARPA , ©BAKER . ARPA : J0E9ABLE . ARPA> 

Example  9 


Time  Stamp  Line  Example 

Received:  FROM  ABC. ARPA  BY  XYZ.ARPA  ;  22  OCT  81  09:23:59  PDT 

Received:  from  ABC. ARPA  by  XYZ.ARPA  via  TELENET  with  X25 

id  M12345  for  SmithdPDQ.ARPA  ;  22  OCT  81  09:23:59  PDT 

Example  10 


Postel 


[Page  33] 


August  1982 

Simple  Mail  Transfer  Protocol 


RPC  821 


4.2.  SMTP  REPLIES 

Replies  to  SMTP  commands  are  devised  to  ensure  the  synchronization 
of  requests  and  actions  in  the  process  of  mail  transfer,  and  to 
guarantee  that  the  sender-SMTP  always  knows  the  state  of  the 
receivei — SMTP.  Every  command  must  generate  exactly  one  reply. 

The  details  of  the  command-reply  sequence  are  mode  explicit  in 

Section  S.3  on  Sequencing  and  Section  5.4  State  Diagrams. 

An  SMTP  reply  consists  of  a  three  digit  number  (transmitted  as 
three  alphanumeric  characters)  followed  by  some  text.  The  number 
is  intended  for  use  by  automata  to  determine  what  state  to  enter 
next;  the  text  is  meant  for  the  human  user,  it  is  intended  that 
the  three  digits  contain  enough  encoded  information  that  the 
sender-SMTP  need  not  examine  the  text  and  may  either  discard  it  or 
pass  it  on  to  the  user,  as  appropriate.  In  particular,  the  text 
may  be  receiver-dependent  and  context  dependent,  so  there  are 
likely  to  be  varying  texts  for  each  reply  code.  A  discussion  of 
the  theory  of  reply  codes  is  given  in  Appendix  E.  Formally,  a 
reply  is  defined  to  be  the  sequence:  a  three-digit  code,  <SP>, 
one  line  of  text,  and  <CRLF>,  or  a  multiline  reply  (as  defined  in 
Appendix  E) .  Only  the  EXPN  and  HELP  commands  are  expected  to 
result  in  multiline  replies  in  normal  circumstances,  however 
multiline  replies  are  allowed  for  any  command. 
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4.2,1.  REPLY  CODES  BY  FUNCTION  GROUPS 


500  Syntax  error,  command  unrecognized 

{This  may  Include  errors  such  as  command  line  too  long] 

501  Syntax  error  in  parameters  or  arguments 

502  Command  not  implemented 

503  Bad  sequence  of  commands 

504  Command  parameter  not  implemented 

211  System  status,  or  system  help  reply 
214  Help  message 

[information  on  how  to  use  the  receiver  or  the  meaning  of  a 
particular  non-standard  command;  this  reply  is  useful  only 
to  the  human  user] 

220  <domain>  Service  ready  """'v 

221  <domain>  Service  closing  transmission  channel 
421  <domain>  Service  not  available, 

closing  transmission  channel 

[This  may  be  a  reply  to  any  command  if  the  service  knows  it 
must  shut  down] 


250  Requested  mail  action  okay,  completed 

251  User  not  local;  will  forward  to  <forward-path> 

450  Requested  mail  action  not  taken:  mailbox  unavailable 
[E.g.,  mailbox  busy] 

550  Requested  action  not  taken:  mailbox  unavailable 
[E.g.,  mailbox  not  found,  no  access] 

451  Requested  action  aborted:  error  in  processing 

551  user  not  local;  please  try  <forward-path> 

452  Requested  action  not  taken:  insufficient  system  storage 

552  Requested  mail  action  aborted:  exceeded  storage  allocation 

553  Requested  action  not  taken:  mailbox  name  not  allowed 
[E.g.,  mailbox  syntax  incorrect] 

354  Start  mail  input;  end  with  <CRLF>.<CRLF>: 

554  Transaction  failed 
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4.2.2.  NUMERIC  ORDER  LIST  OF  REPLY  COOES 

211  System  status,  or  system  help  reply 
214  Help  message 

[Information  on  how  to  use  the  receiver  or  the  meaning  of  a 
particular  non-standard  command;  this  reply  is  useful  only 
to  the  human  user] 

220  <domain>  Service  ready 

221  <domain>  Service  closing  transmission  channel 

250  Requested  mail  action  okay,  completed 

251  User  not  Ideal;  will  forward  to  <f orward-path> 

354  Start  mail  input;  end  with  <CRLF>. <CRLF> 

421  <domain>  service  not  available, 
closing  transmission  channel 

[This  may  be  a  reply  to  any  command  if  the  service  knows  it 
must  shut  down] 

450  Requested  mail  action  qot  taken:  mailbox  unavailable 
[E.g.,  mailbox  busy] 

451  Requested  action  aborted:  local  error  in  processing 

452  Requested  action  not  taken:  insufficient  system  storage 

500  Syntax  error,  command  unrecognized 

[This  may  include  errors  such  as  command  line  too  long] 

501  Syntax  error  in  parameters  or  arguments 

502  Command  not  implemented 

503  Bad  sequence  of  commands 

504  Command  parameter  not  implemented 

550  Requested  action  not  taken:  mailbox  unavailable 
[E.g.,  mailbox  not  found,  no  access] 

551  user  not  local;  please  try  <forward-path> 

552  Requested  mail  action  aborted:  exceeded  storage  allocation 

553  Requested  action  not  taken:  mailbox  name  not  allowed 
[E.g.,  mailbox  syntax  incorrect] 

554  Transaction  failed 
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4.3.  SEQUENCING  OF  COMMANDS  AND  REPLIES 

The  communication  between  the  sender  and  receiver  is  intended  to 
be  an  alternating  dialogue,  controlled  by  the  sender.  As  such, 
the  sender  issues  a  command  and  the  receiver  responds  with  a 
reply.  The  sender  must  wait  for  this  response  before  sending 
further  commands. 

One  important  reply  is  the  connection  greeting.  Normally,  a 
receiver  will  send  a  220  "Service  ready”  reply  when  the  connection 
is  completed.  The  sender  should  wait  for  this  greeting  message 
before  sending  any  commands. 

Note:  all  the  greeting  type  replies  have  the  official  name  of 
the  server  host  as  the  first  word  following  the  reply  code. 

For  example, 

220  <SP>  USC—ISIF . ARPA  <SP>  Service  ready  <CRLF> 

The  table  below  lists  alternative  success  and  failure  replies  for 
each  command.  These  must  be  strictly  adhered  to;  a  receiver  may 
substitute  text  in  the  replies,  but  the  meaning  and  action  implied 
by  the  code  numbers  and  by  the  specific  command  reply  sequence 
cannot  be  altered. 

COMMAND-REPLY  SEQUENCES 

Each  command  is  listed  with  its  possible  replies.  The  prefixes 
used  before  the  possible  replies  are  ”P"  for  preliminary  (not 
used  in  SMTP),  "I"  for  intermediate,  "S"  for  success,  "F"  for 
failure,  and  "E"  for  error.  The  421  reply  (service  not 
available,  closing  trar emission  channel)  may  be  given  to  any 
command  if  the  SMTP-receiver  knows  it  must  shut  down.  This 
listing  forms  the  basis  for  the  State  Diagrams  in  Section  4.4. 

CONNECTION  ESTABLISHMENT 
S:  220 
F :  421 
HELO 

S:  250 

E:  500,  501,  504,  421 
MAIL 

S:  250 

F:  552,  451,  452 
E:  500,  501,  421 
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RCPT 

S:  250.  251 

P:  550,  651.  552.  553.  450.  451.  452 
E:  500.  501.  503.  421 
DATA 

X:  354  ->  data  ->  S:  250 

F:  652,  664,  451,  452 


Fs 

E: 

451,  554 
500.  501. 

503, 

421 

RSET 

S: 

E: 

250 

500,  601, 

504, 

421 

SEND 

S: 

P: 

E: 

250 

552.  451. 
500,  501, 

452 

502, 

421 

SOML 

S: 

F: 

E: 

250 

552,  451. 
500,  501, 

452 

502, 

421 

SAML 

S: 

F: 

E: 

250 

552.  451, 
500,  501, 

452 

502. 

421 

VRFY 

S: 

F: 

E: 

250,  251 
550,  551, 
500,  501. 

553 

502, 

504 

EXPN 

S:  250 
F:  550 


E: 

500, 

601, 

502, 

504, 

421 

HELP 

S: 

211. 

214 

E: 

500, 

501, 

502, 

504, 

421 

NOOP 

S: 

250 

E: 

500, 

421 

QUIT 

S: 

221 

E: 

500 

TURN 

S: 

250 

F: 

502 

E: 

500, 

503 
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4.4.  STATE  DIAGRAMS  ■ 

Following  are  state  diagrams  for  a  simple-minded  SMTP 
implementation.  Only  the  first  digit  of  the  reply  codes  is  used. 
There  i a  one  state  diagram  for  each  group  of  SMTP  commands.  The 
command  groupings  were  determined  by  constructing  a  model  for  each 
command  and  then  collecting  together  the  commands  with 
structurally  identical  models. 

For  each  command  there  are  three  possible  outcomes:  "success" 

(S).  "failure"  (F).  and  "error"  (E).  in  the  state  diagrams  below 
we  use  the  symbol  B  for  "begin",  and  the  symbol  w  for  "wait  for 
reply" . 

First,  the  diagram  that  represents  most  of  the  SMTP  commands: 


+ - + 

|  B  | - 

+ - + 


cmd 


1.3  +—— + 

- >1  E  I 

|  + - + 

I 

+ +  2  + — -+ 

— >|  "4 - >|  S  | 


4,5 


->l  F 


This  diagram  models  the  commands: 

HELO,  MAIL,  RCPT,  RSfeT,  SEND.  SOML,  SAML,  VRFY,  EXPN,  HELP, 
NOOP.  GUIT,  TURN. 
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Note  that  the  "data"  here  is  a  series  of  lines  sent  from  the 
sender  to  the  receiver  with  no  response  expected  until  the  last 
line  is  sent. 
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4.5.  DETAILS 

4.5.1.  MINIMUM  IMPLEMENTATION 

In  order  to  make  SMTP  workable,  the  following  minimum 
implementation  is  required  for  all  receivers: 

COMMANDS  —  HELO 
MAIL 
RCPT 
DATA 
RSET 
NOOP 
QUIT 

4.5.2.  TRANSPARENCY 

Without  some  provision  for  data  transparency  the  character 
sequence  "<CRLF>. <CRLF>"  ends  the  mail  text  and  cannot  be  sent 
by  the  user,  in  general,  users  are  not  aware  of  such 
"forbidden"  sequences.  To  allow  all  user  composed  text  to  be 
transmitted  transparently  the  following  procedures  are  used. 

1.  Before  sending  a  line  of  mail  text  the  sender-SMTP  checks 
the  first  character  of  the  line.  If  it  is  a  period,  one 
additional  period  is  inserted  at  the  beginning  of  the  line. 

2.  when  a  line  of  mail  text  is  received  by  the  receiver-SMTP 
it  checks  the  line.  If  the  line  is  composed  of  a  single 
period  it  is  the  end  of  mail.  If  the  first  character  is  a 
period  and  there  are  other  characters  on  the  line,  the  first 
character  is  deleted. 

The  mail  data  may  contain  any  of  the  128  ASCII  characters.  All 
characters  are  tc  be  delivered  to  the  recipient's  mailbox 
including  format  effectors  and  other  control  characters.  If 
the  transmission  channel  provides  an  8-bit  byte  (octets)  data 
stream,  the  7-bit  ASCII  codes  are  transmitted  right  justified 
in  the  octets  with  the  high  order  bits  cleared  to  zero. 

In  some  systems  it  may  be  necessary  to  transform  the  data  as 
it  is  received  and  stored.  This  may  be  necessary  for  hosts 
that  ><?e  a  different  character  set  than  ASCII  as  their  local 
character  set,  or  that  store  data  in  records  rather  than 
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Strings.  Zf  such  transforms  are  necessary,  they  must  be 
reversible  —  especially  if  such  transforms  are  applied  to 
mail  being  relayed. 

4.5.3.  SIZES 

There  are  several  objects  that  have  required  minimum  maximum 
sizes.  That  is.  every  implementation  must  be  able  to  receive 
objects  of  at  least  these  sizes,  but  must  not  send  objects 
larger  than  these  sizes. 


•  TO  THE  MAXIMUM  EXTENT  POSSIBLE.  IMPLEMENTATION 

•  TECHNIQUES  WHICH  IMPOSE  NO  LIMITS^ON  THE  LENGTH 

•  OF  THESE  OBJECTS  SHOULD  BE  USED.  ^ 


user 

The  maximum  total  length  of  a  user  name  is  64  characters, 
domain 

The  maximum  total  length  of  a  domain  name  or  number  is  64 
characters. 

path 

The  maximum  total  length  of  a  reverse-path  or 
forward-path  is  256  characters  (including  the  punctuation 
and  element  separators). 

command  line 

The  maximum  total  length  of  a  command  line  including  the 
command  word  and  the  <CRLF>  is  512  characters. 

reply  line 

The  maximum  total  length  of  vj^-eply  line  including  the 
reply  code  and  the  <CRLF>  is  >12  characters. 
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text  line 

The  maximum  total  length  of  a  text  line  including  the 
<CRLF>  is  1000  characters  (but  not  counting  the  leading 
dot  duplicated  for  transparency). 

recipients  buffer 

The  maximum  total  number  of  recipients  that  must  be 
buffered  is  loo  recipients. 


•  TO  THE  MAXIMUM  EXTENT  POSSIBLE.  IMPLEMENTATION 

•  TECHNIQUES  WHICH  IMPOSE  NO  LIMITS  ON  THE  LENGTH 

•  OF  THESE  OBJECTS  SHOULD  BE  USED. 


Errors  due  to  exceeding  these  limits  may  be  reported  by  using 
the  reply  codes,  for  example: 

500  Line  too  long. 

501  Path  too  long 

552  Too  many  recipients. 

552  Too  much  mail  data. 
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APPENDIX  A 

TCP  Transport  service 

The  Transmission  Control  Protocol  [3]  is  used  in  the  ARPA 
Internet,  and  in  any  network  following  the  US  DoD  standards  for 
internetwork  protocols. 

Connection  Establishment 

The  SMTP  transmission  channel  is  a  TCP  conneotion  established 
between  the  sender  process  port  U  and  the  receiver  process  port 
L.  This  single  full  duplex  conneotion  is  used  as  the 
transmission  channel.  This  protocol  is  assigned  the  service 
port  25  (31  octal),  that  is  L«25. 

Data  Transfer 

The  TCP  connection  supports  the  transmission  of  8-bit  bytes. 

The  SMTP  data  is  7-bit  ASCII  characters.  Each  character  is 
transmitted  as  ah  f-bit  byte  with  the  high-order  bit  cleared  to 
zero. 
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APPEN01X  B 

NCP  Transport  service 

The  ARPANET  Host-to-Host  Protocol  [4]  (implemented  by  the  Network 
Control  Program)  may  be  used  in  the  ARPANET. 

Connection  Establishment 

The  SMTP  transmission  channel  is  established  via  NCP  between 
the  sender  process  socket  U  and  receiver  process  socket  L.  The 
Initial  Connection  Protocol  (5]  is  followed  resulting  in  a  pair 
of  simplex  connections.  This  pair  of  connections  is  used  as 
the  transmission  channel.  This  protocol  is  assigned  the 
contact  socket  28  (31  octal),  that  is  L-25. 

Data  Transfer 

The  NCP  data  connections  are  established  in  8-bit  byte  mode. 

The  SMTP  data  is  7-blt  ASCII  characters.  Each  character  is 
transmitted  as  an  8-bit  byte  with  the  high-order  bit  cleared  to 
zero. 
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APPENDIX  C 
NITS 

The  Network  independent  Transport  Service  [6]  may  be  used. 
Connection  Establishment 

The  SMTP  transmission  channel  is  established  via  NITS  between 
the  sender  process  and  receiver  process.  The  sender  process 
executes  the  CONNECT  primitive,  and  the  waiting  receiver 
process  executes  the  ACCEPT  primitive. 

Oata  Transfer 

The  NITS  connection  supports  the  transmission  of  8-bit  bytes. 
The  SMTP  data  is  7-bit  ASCII  characters.  Each  character  is 
transmitted  as  an  8-bit  byte  with  the  high-order  bit  cleared  to 
zero. 
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APPENDIX  D 

X. 25  Transport  service 

it  may  be  possible  to  use  the  X.25  service  [7]  as  provided  by  the 
Public  Data  Networks  directly,  however,  it  is  suggested  that  a 
reliable  end-to-end  protocol  such  as  TCP  be  used  on  top  of  X.25 
connections. 
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APPENDIX  E 

Theory  of  Reply  Codes 

The  three  digits  of  the  reply  each  have  a  special  significance. 

The  first  digit  denotes  whether  the  response  is  good,  bad  or 
incomplete.  An  unsophisticated  sender-SMTP  will  be  able  to 
determine  its  next  action  (proceed  as  planned,  redo,  retrench, 
etc.)  by  simply  examining  this  first  digit.  A  sender-SMTP  that 
wants  to  know  approximately  what  kind  of  error  occurred  (e.g., 
mail  system  error,  command  syntax  error)  may  examine  the  second 
digit,  reserving  the  third  digit  for  the  finest  gradation  of 
information. 

There  are  five  values  for  the  first  digit  of  the  reply  code: 

lyz  Positive  Preliminary  reply 

The  command  has  been  accepted,  but  the  requestad  action 
is  being  held  in  abeyance,  pending  confirmation  of  the 
information  in  this  reply.  The  sendei — SMTP  should  send 
another  command  specifying  whether  to  continue  or  abort 
the  action. 

[Note:  SMTP  does  not  have  any  commands  that  allow  this 
type  of  reply,  and  so  does  not  have  the  continue  or 
abort  commands.] 

2yz  Positive  Completion  reply 

The  requested  action  has  been  successfully  completed.  A 
new  request  may  be  initiated. 

3yz  Positive  Intermediate  reply 

The  command  has  been  accepted,  but  the  requested  action 
is  being  held  in  abeyance,  pending  receipt  of  further 
information.  The  sender-SMTP  should  send  another  command 
specifying  this  information.  This  reply  is  used  in 
command  sequence  groups. 

4yz  Transient  Negative  Completion  reply 

The  command  was  not  accepted  and  the  requested  action  did 
not  occur.  However,  the  error  condition  is  temporary  and 
the  action  may  be  requested  again.  The  sender  should 
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return  to  the  beginning  of  the  command  sequence  (if  any), 
it  is  difficult  to  assign  a  meaning  to  "transient”  Nhen 
two  different  sites  (receiver-  and  sender-  SMTPs)  must 
agree  on  the  interpretation .  Each  reply  in  this  category 
might  have  a  different  time  value,  but  the  sender-SMTP  is 
encouraged  to  try  again.  A  rule  of  thumb  to  determine  if 
a  reply  fits  into  the  4yz  or  the  5yz  category  (see  below) 
is  that  replies  are  4yz  if  they  can  be  ropeated  without 
any  change  in  command  form  or  in  properties  of  the  sender 
or  receiver.  (E.g..  the  command  is  repeated  identically 
and  the  receiver  does  not  put  up  a  new  implementation.) 

Syz  Permanent  Negative  Completion  reply 

The  command  was  not  accepted  and  the  requested  action  did 
not  occur.  The  sender-SMTP  is  discouraged  from  repeating 
the  exact  request  (in  the  same  sequence).  Even  some 
"permanent"  error  conditions  can  be  corrected,  so  the 
human  user  may  want  to  direct  the  sender-SMTP  to 
reinitiate  the  command  sequence  by  direct  action  at  some 
point  in  the  future  (e.g.,  after  the  spelling  has  been 
changed,  or  the  user  has  altered  the  account  status). 

The  second  digit  encodes  responses  in  specific  categories: 

xOz  Syntax  —  These  replies  refer  to  syntax  errors, 

syntactically  correct  commands  that  don't  fit  any 
functional  category,  and  unimplemented  or  superfluous 
commands. 

xlz  information  —  These  are  replies  to  requests  for 
information,  such  as  status  or  help. 

x2z  Connections  —  These  are  replies  referring  to  the 
transmission  channel. 

x3z  Unspecified  as  yet. 

x4z  unspecified  as  yet. 

x5z  Mail  system  —  These  replies  indicate  the  status  of 
the  receiver  mail  system  vis-a-vis  the  raquested 
transfer  or  other  mail  system  action. 

The  third  digit  gives  a  finer  gradation  of  meaning  in  each 
category  specified  by  the  second  digit.  The  list  of  replies 
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illustrates  this.  Each  reply  text  is  recommended  rather  than 
mandatory,  and  may  even  change  according  to  the  command  with 
which  it  is  associated.  On  the  other  hand,  the  reply  codes 
must  strictly  follow  the  specif ications  in  this  section. 
Receiver  implementations  should  not  invent  new  codes  for 
slightly  different  situations  from  the  ones  described  here,  but 
rather  adapt  codes  r.lready  defined. 

Por  example,  a  command  such  as  NOOP  whose  successful  execution 
does  not  offer  the  sender-SMTP  any  new  information  will  return 
a  250  reply.  The  response  is  502  when  the  command  requests  an 
unimplemented  non-site-specific  action.  A  refinement  of  that 
is  the  504  reply  for  a  command  that  is  implemented,  but  that 
requests  an  unimplemented  parameter. 

The  reply  text  may  be  longer  than  a  single  line;  in  these  cases 
the  complete  text  must  be  marked  so  the  sender-SMTP  knows  when  it 
can  stop  reading  the  reply.  This  requires  a  special  format  to 
indicate  a  multiple  line  reply. 

The  format  for  multiline  replies  requires  that  every  line, 
except  the  last,  begin  with  the  reply  code,  followed 
immediately  by  a  hyphen,  (also  known  as  minus),  followed  by 

text.  The  last  line  will  begin  with  the  reply  code,  followed 
immediately  by  <SP>, . optionally  some  text,  and  <CRLF>. 

For  example: 

123-First  line 
123-Second  line 

123-234  text  beginning  with  numbers 
123  The  last  line 

In  many  cases  the  sender-SMTP  then  simply  needs  to  search  for 
the  reply  code  followed  by  <SP>  at  the  beginning  of  a  line,  and 
ignore  all  preceding  lines,  in  a  few  cases,  there  is  important 
data  for  the  sender  in  the  reply  "text".  The  sender  will  know 
these  cases  from  the  current  context. 
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APPENDIX  F 
Scenarios 

This  section  presents  complete  scenarios  of  several  types  of  SMTP 
sessions. 

A  Typical  SMTP  Transaction  Scenario 

This  SMTP  example  shows  mail  sent  by  Smith  at  host  USC-ISIF,  to 
Jones,  Green,  and  Brown  at  host  BBN-UNXX.  Here  we  assume  that 
host  USC-XSXF  contacts  host  BBN-UNXX  directly.  The  mail  is 
accepted  for  Jones  and  Brown.  Green  does  not  have  a  mailbox  at 
host  BBN-UNXX. 


R:  220  BBN-UNXX. ARPA  Simple  Mail  Transfer  Service  Ready 
S:  HEl.O  USC-XSXF. ARPA 
R:  250  BBN— UNIX . ARPA 

S:  MAIL  FROM: <SmithOUSC— XSXF . ARPA> 

R:  250  Or 

S:  RCPT  TO: <Jones08BN— UNIX. ARPA> 

R:  250  OK 

S:  RCPT  TO: <Green03BN-UNIX. ARPA> 

R:  550  No  such  user  here 

S:  RCPT  TO: <Brown9BBN-UNIX. ARPA> 

R:  250  OK 

S:  DATA 

R:  354  Start  mail  input;  end  with  <CRUF>. <CRLF> 

S:  Blah  blah  blah. . . 

S:  ...etc.  etc.  etc. 

S:  . 

R:  250  OK 


S:  QUIT 

R:  221  BBN-UNXX. ARPA  Service  closing  transmission  channel 

Scenario  1 
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Aborted  SMTP  Transaction  Scenario 


R:  220  MZT-Multics . ARP A  Simple  Mail  Transfer  Service  Ready 
S:  HELO  I SI— VAX A . ARP A 
R:  2S0  MIT— Mu 1 tics. ARP A 

S:  MAIL  FROM: <SmithOZSI-VAXA. ARPA> 

R:  250  OK 

S:  RCPT  TO: <JonesOMIT— Multics . ARPA> 

R:  250  OK 

S:  RCPT  TO: <GreenOMIT— Multics. ARPA> 

R:  550  no  such  user  here 

S:  RSET 
R:  250  OK 

S:  QUIT 

R:  221  MIT-;  ultics.ARPA  Service  closing  transmission  channel 

Scenario  2 
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Step  1  —  Source  Host  to  Relay  Host 

R:  220  USC— ISXE . ARPA  Simple  Mail  Transfer  Service  Ready 
S:  HELO  M1T-AZ.ARPA 
R:  250  USC-XSZE.ARPA 

S:  MAIL  FROM : < JQPOMIT— AX . ARPA> 

R:  250  OK 

S:  RCPT  TO: <0USC-XSXE .ARPA: JonesOBBN— VAX . ARPA> 

R:  250  OK 

DATA 

354  Start  mail  input:  end  with  <CRLF>. <CRLF> 

Data:  2  Nov  81  22:33:44 
From:  John  Q.  Public  <JQPOMXT-AI.ARPA> 

Subject:  The  Next  Meeting  of  the  Board 
To:  JonesOBBN— Vax . ARPA 

Bill: 

The  next  meeting  of  the  board  of  directors  will  be 
on  Tuesday. 

John. 

250  OK 
S:  QUIT 

R:  221  USC-ISIE. ARPA  Service  closing  transmission  channel 
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Step  2  —  Relay  Host  to  Destination,  Host 

R:  220  BBN— VAX. ARPA  Simple  Mail  Transfer  Service  Ready 
S:  HELO  USC-ISZE . ARPA 
R:  250  BBN— VAX. ARPA 

S:  MAIL  FROM 3 <0USC— XSX E . ARPA : JQPOMXT— AX . ARPA> 

R:  250  OK 

S:  RCPT  TO: <Jones8BBN— VAX. ARPA> 

R:  250  OK 

S:  DATA 

R:  354  Start  mail  input;  end  with  <CRLF>.<CRLF> 

S:  Received:  from  MXT-AX . ARPA  by  USC-XSXE.ARPA  ; 

2  NOV  81  22:40:10  UT 
Date:  2  Nov  81  22:33:44 
From:  John  Q.  Public  < JQPOMXT-AX . ARPA> 

Subject:  The  Next  Meeting  of  the  Board 
To:  JonesOBBN— Vax . ARPA 

Bill: 

The  next  meeting  of  the  board  of  directors  will  be 
on  Tuesday. 

John. 

250  OK 
S:  QUIT 

R:  221  USC-ISIE. ARPA  Service  closing  transmission  channel 

Scenario  3 
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Verifying  and  Sending  Scenario 


R:  220  SU-SCORE. ARPA  Simple  Mail  Transfer  Service  Ready 
S:  HELO  MIT— MC. ARPA 
R:  250  SU-SCQRE . ARPA 


S:  VRFY  Crispin 

R:  250  Mark  Crispin  <Admin . MRCOSU-SCORE . ARPA> 

S:  SEND  FROM : <EAK0MXT— MC . ARPA> 

R:  250  OK 


S:  RCPT  TO : < Admin . MRCOSU-SCORE . ARPA> 

R:  250  OK 

S:  DATA 

R:  354  Start  mail  input;  end  with  <CRLF> . <CRLF> 

S:  Blah  blah  blah. . . 

S:  . . .etc.  etc.  etc. 

Ss  . 

Rs  250  OK 
Ss  QUIT 

R:  221  SU-5C0RE. ARPA  Service  closing  transmission  channel 

Scenario  4 
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Sending  and  Mailing  Scenarios 

First  the  user's  nam*  is  verified,  then  an  attempt  is  made  to 
send  to  the  user's  terminal.  When  that  fails,  the  messages  is 
mailed  to  the  user's  mailbox. 


R:  220  SU-SCORE. ARPA  Simple  Mall  Transfer  Service  Ready 
S:  HELO  MIT— MC. ARPA 
R:  250  SU-SCORE. ARPA 

S:  VRFY  Crispin 

R:  250  Mark  Crispin  <Admin . MRCOSU-SCORE . ARPA> 

S:  SEND  FROM: <EAK0MIT— MC. ARPA> 

R:  250  OK 

S:  RCPT  TO:<Admin. MRCOSU-SCORE. ARPA> 

R:  450  User  not  active  non 


S:  RSET 
R:  250  OK 

S:  MAIL  FROM: <EAK0MIT— MC. ARPA> 

R:  250  OK 

S:  RCPT  TO: <Admin. MRCOSU-SCORE. ARPA> 

R:  250  OK 

S:  DATA 

R:  354  Start  mail  input;  end  nith  <CRLF>. <CRLF> 

S:  Blah  blah  blah... 

S:  _ etc.  etc.  etc. 

S :  . 

R:  250  OK 
S:  QUIT 

R:  221  SU— SC'-r  . AR 3A  service  closing  transmission  channel 


O 


Scenario  5 
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Doing  the  preceding  scenario  more  efficiently. 


R: 

S: 

R: 

S: 

R: 

S: 

R: 

S: 

R: 

S: 

R: 

S: 

S: 

S: 

R: 

S: 

R: 


220  su— SCORE . ARPA  Simple  Mail  Transfer  Service  Ready  , 
HELO  MIT— MC. ARPA 

250  SU-SCORE . ARPA 

VRFY  Crispin 

250  Mark  Crispin  <Admin.MRC0SU-SC0RE. ARPA> 

SOML  FROM: <EAKOMIT-MC. ARPA> 

250  OK 

RCPT  TO : <Admin . MRCOSU-SCORE . ARPA> 

250  user  not  active  now,  so  will  do  mail. 

DATA 

354  Start  mail  input;  and  with  <CRLF>.<CRLF> 

Blah  blah  blah. . . 

...etc.  etc.  etc. 

250  OK 

OUIT 

221  SU-SCORE. ARPA  Service  closing  transmission  channel 

Scenario  6 
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Mailing  List  Scenario 

First  each  of  two  mailing  lists  are  expanded  in  separate  sessions 
with  different  hosts.  Then  the  message  is  sent  to  everyone  that 
appeared  on  either  list  (but  no  duplicates)  via  a  relay  host. 


Step  1  —  Expanding  the  First  List 

R:  220  mzt-ax.ARPA  Simple  Mail  Transfer  Service  Ready 
S:  HELO  SU-SCORE. ARPA 
R:  2S0  MIT— AI .ARPA 

S:  EXPN  Example-People 
R:  250— <ABC0MIT— MC.ARPA> 

R:  250-Fred  Fonebone  <FoneboneOUSC-ISIQ. ARPA> 

R:  250-Xenon  Y.  Zither  <XYZ8MIT— AX . ARPA> 

R:  250-Quincy  Smith  <9USC-XSIF. ARPA:Q-SmithOISI-VAXA. ARPA> 
R:  250-<joe0foo— unix. ARPA> 

R:  250  <xyzObar— unix. ARPA> 

S:  QUIT 

R:  221  MIT— AI . ARPA  Service  closing  transmission  channel 
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Step  2  - —  Expanding  the  Second  List 

R:  220  mit-mc.  *.RPA  Simple  Mail  Transfer  Service  Ready 
S:  HELO  SU— SCORE. ARP A 
R:  2S0  MZT-MC.ARPA 

S:  EXPN  Interested-Parties 
R:  2S0-A1  Calico  <ABCOMIT-MC. ARPA> 

Rj  250— <XYZ0MIT— AX . ARPA> 

R:  250-Qulncy  Smith  <0USC-XSXF . ARPA : O-Smi thOISI-VAXA. ARPA> 
R:  250— <f redOBBN-UNIX . ARPA> 

R:  250  <xyzdbar— unix . ARPA> 

S:  QUIT 

R:  221  MIT— MC. ARPA  Service  closing  transmission  channel 


Postal 


[Page  59] 


August  1982 

Simple  Mail  Transfer  Protocol 


RFC  821 


Step  3  —  Mailing  to  All  via  a  Relay  Host 

R:  220  USC-ISIE. ARPA  simple  Mail  Transfer  service  Ready 
S:  HELO  SU— SCORE . ARPA 
R:  280. USC-XSXE. ARPA 

S:  MAIL  FROM : <Account . Par sonOSU— SCORE . ARPA> 

R:  280  OK 

S:  RCPT  TO: <OUSC— ISIE . ARPA : ABCOMXT-MC . ARPA> 

R:  260  OK 

S:  RCPT  TO: <0USC-XSXE. ARPA: FoneboneeUSC-ISIQA. ARPA> 

R:  280  OK 

S:  RCPT  TO: <0USC— XSXE . ARPA: XYZ8MXT— AX . ARPA> 

R:  280  OK 
S:  RCPT 

TO: <OUSC— ZSZE . ARPA , 0USC-ISIF . ARPA : Q-Smi theiSI-VAXA . ARPA> 
R:  280  OK 

S:  RCPT  TO: <OUSC~XSXE . ARPA: joeOFOO-UNZX . ARPA> 

R:  280  OK 

S:  RCPT  TO : <OUSC— ZSZE . ARPA : xy zOBAR— UNIX . ARPA> 

R:  280  OK 

S:  RCPT  TO : <OUSC— ISIE . ARPA : f redOBBN— UNIX . ARPA> 

R:  250  OK 

S:  DATA 

R:  354  Start  mail  input:  end  with  <CRLF>. <CRLF> 

S:  Blah  blah  blah. . . 

S:  ...etc.  etc.  etc. 

S: 

R:  250  OK 
S:  QUIT 

R:  221  USC— ISIE . ARPA  Service  closing  transmission  channel 

Scenario  7 
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Forwarding  Scenarios 


R:  220  USC-IS1F. ARPA  Simple  Mail  Transfer  Service  Ready 
S:  HELD  LBL-UNIX . ARPA 
R:  250  USC— ISIF . ARPA 

S:  MAIL  FROM  s  <modLBL— UNIX . ARPA> 

R:  250  OK 

Ss  RCPT  TO: <f redOUSC-ISIF . ARPA> 

R:  251  User  not  local;  will  forward  to  < JonesOUSC-XSI . ARPA> 
S:  DATA 

R:  364  Start  mail  input;  end  with  <CRLF>. <CRLF> 

S:  Blah  blah  blah... 

S:  ...etc.  etc.  etc. 

S:  . 

R:  250  OK 
S:  QUIT 

R:  221  USC-ISIF. ARPA  Service  closing  transmission  channel 

Scenario  8 
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Step  1  —  Trying  the  Mailbox  at  the  First  Host 

R:  220  USC— ISIF.ARPA  Simple  Mail  Transfer  Service  Ready 
S:  HELO  LBL— UNIX . ARPA 
R:  250  U5C-1SIF . ARPA 

S:  MAIL  FROM: <moOLBL-UNIX. ARPA> 

R:  250  OK 

S:  RCPT  TO: <f redOUSC-ISXF . ARPA> 

R:  251  User  not  local;  will  forward  to  <JonestUSC-XSX.ARPA> 

S:  RSET 
R:  250  OK 

S:  QUIT 

R:  221  USC— XSIF . ARPA  Service  closing  transmission  channel 

Step  2  —  Delivering  the  Mail  at  the  Second  Host 

R:  220  USC— XSX . ARPA  Simple  Mail  Transfer  Service  Ready 
S:  HELO  LBL-UNXX . ARPA 
R:  250  USC— XSX . ARPA 

S:  MAIL  FROM : <moOLBL— UNIX . ARPA> 

R:  250  OK 

S:  RCPT  TO : < JonesOUSC— XSX . ARP A> 

R:  OK 

S:  DATA 

R:  354  Start  mail  input;  end  with  <CRLF>. <CRLF> 

S:  Blah  blah  blah. . . 

S:  ...etc.  etc.  etc. 

S:  . 

R:  250  OK 
S:  QUIT 

R:  221  USC— ISX . ARPA  Service  closing  transmission  channel 

Scenario  9 
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Too  Many  Recipients  Scenario 


R:  220  BERKELEY. ARPA  Simple  Mall  Transfer  Service  Ready 
S:  MELO  USC—ISIF . ARPA 
R:  250  BERKELEY. ARPA 

S:  MAIL  FROM: <Postel#USC-ISIF . ARPA> 

R:  250  OK 

S:  RCPT  TO: <f abryOBERKELEY . ARPA> 

R:  250  OK 

S:  RCPT  TO: <er icOBERKELEY . ARPA> 

R:  552  Recipient  storage  full,  try  strain  in  another  transaction 
S:  DATA 

R:  354  Start  mail  input;  end  with  <CRLF>  <CRLF> 

S:  Blah  blah  blah... 

S:  ...etc.  etc.  etc. 

S:  . 

R:  250  OK 

S:  MAIL  FROM : <Postel6USC— ISIF . ARPA> 

R:  250  OK 

S:  RCPT  TO: <er icBBERKELEY. ARPA> 

R:  250  OK 

S:  DATA 

R:  354  Start  mail  input;  end  with  <CRLF>. <CRLF> 

S:  Blah  blah  blah... 

S:  ...etc.  etc.  etc. 

S:  . 

R:  250  OK 
S:  QUIT 

R:  221  BERKELEY. ARPA  Service  closing  transmission  channel 

Scenario  10 


Note  that  a  real  implementation  must  handle  many  recipients  as 
specified  in  Section  4.5.3. 
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GLOSSARY 

ASCII 

American  Standard  Code  for  Information  Interchange  (1). 
command 

A  request  for  a  mail  service  action  sent  by  the  sender-SMTP  to  the 
receiver-SMTP. 

domain 

The  hierarchially  structured  global  character  string  address  of  a 
host  computer  in  the  mail  system. 

end  of  mail  data  indication 

A  special  sequence  of  characters  that  indicates  the  end  of  the 
mail  data,  in  particular,  the  five  characters  carriage  return, 
line  feed,  period,  carriage  return,  line  feed,  in  that  order. 

host 

A  computer  in  the  internetwork  environment  on  which  mailboxes  or 
SMTP  processes  reside. 

line 

A  a  sequence  of  ASCII  characters  ending  with  a  <CRLF>. 
mail  data 

A  sequence  of  ASCII  characters  of  arbitrary  length,  which  conforms 
to  the  standard  set  in  the  Standard  for  the  Format  of  arpa 
Internet  Text  Messages  (RFC  822  (2]>. 

mailbox 

A  character  string  (address)  which  Identifies  a  user  to  whom  mail 
is  to  be  sent.  Mailbox  normally  consists  of  the  host  and  user 
specifications.  The  standard  mailbox  naming  convention  is  defined 
to  be  "userOdomain" .  Additionally,  the  "container"  in  which  mail 
is  stored. 
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receiver-SMTP  process 

A  process  which  transfers  mall  in  cooperation  with  a  sender-SMTP 
process.  Zt  waits  for  a  connection  to  be  established  via  the 
transport  service,  zt  receives  SMTP  commands  from  the 
sender-SMTP.  sends  replies,  and  performs  the  specified  operations. 

reply 

A  reply  is  an  acknowledgment  (positive  or  negative)  sent  from 
receiver  to  sender  via  the  transmission  channel  in  response  to  a 
command.  The  general  fora  of  a  reply  is  a  completion  code 
(including  error  codes)  followed  by  a  text  string.  The  codes  are 
for  use  by  programs  and  the  text  is  usually  intended  for  human 
users. 

sender-SMTP  process 

A  process  which  transfers  nail  in  cooperation  wich  a  receiver-SMTP 
process.  A  local  language  may  be  used  in  the  user  interface 
command/reply  dialogue.  The  sender-SMTP  initiates  the  transport 
service  connection.  Zt  initiates  SMTP  commands,  receives  replies, 
and  governs  the  transfer  of  mril; 

session 

The  set  of  exchanges  that  occur  while  the  transmission  channel  is 
open. 

transaction 

The  set  of  exchanges  required  for  one  message  to  be  transmitted 
for  one  or  more  recipients. 

transmission  channel 

A  full-duplex  communication  path  between  a  sender-SMTP  and  a 
receiver-SMTP  for  the  exchange  of  commands,  replies,  and  mail 
text. 

transport  service 

Any  reliable  stream-oriented  data  communication  services;  For 
example.  NCP,  TCP,  NZTS. 
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user 

A  huaan  being  (or  a  process  on  behalf  of  a  huean  being)  wishing  to 
obtain  wall  transfer  service,  xn  addition,  a  recipient  of 
coaputer  aail. 

word 

A  sequence  of  printing  characters. 

<CRLF> 

The  characters  carriage  return  and  line  feed  (in  that  order). 

<SP> 

The  space  character. 
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PREFACE 


By  1977,  the  Arpanet  employed  several  informal  standards  for 
the  text  messages  (mail)  sent  among  its  host  computers.  It  was 
felt  necessary  to  codify  these  practices  and  provide  for  those 
features  that  seemed  imminent.  The  result  of  that  effort  was 
Request  for  Comments  (RFC)  #733,  "Standard  for  the  Format  of  ARPA 
Network  Text  Message",  by  Crocker,  vitt.il,  Pogran,  and  Henderson. 
The  specification  attempted  to  avoid  ma^or  changes  in  existing 
software,  while  permitting  several  new  features. 

This  document  revises  the  specifications  in  RFC  #733,  in 
order  to  serve  the  needs  of  the  larger  and  more  complex  ARPA 
Internet.  Some  of  RFC  #733*s  features  failed  to  gain  adequate 
acceptance.  In  order  to  simplify  the  standard  and  the  software 
that  follows  it,  these  features  have  been  removed.  A  different 
addressing  scheme  is  used,  to  handle  the  case  of  inter-network 
mail;  and  the  concept  of  re-transmission  has  been  introduced. 

This  specification  is  intended  for  use  in  the  ARPA  Internet. 
However,  an  attempt  has  been  made  to  free  it  of  any  dependence  on 
that  environment,  so  that  it  can  be  applied  to  other  network  text 
message  systems. 

The  specification  of  RFC  #733  took  place  over  the  course  of 
one  year,  using  the  ARPANET  mail  environment,  itself,  to  provide 
an  on-going  forum  for  discussing  the  capabilities  to  be  included. 
More  than  twenty  individuals,  from  across  the  country,  partici¬ 
pated  in  thti  original  discussion.  The  development  of  this 
revised  specification  has,  similarly,  utilized  network  mail-based 
group  discussion.  Both  specification  efforts  greatly  benefited 
from  the  comments  and  ideas  of  the  participants. 

The  syntax  of  the  standard,  in  RFC  #733,  was  originally 
specified  in  the  Backus-Naur  Form  (8NF)  meta-language.  Ken  L. 
H&rrenstien,  of  SRI  International,  was  responsible  for  re-coding 
the  BNF  into  an  augmented  bnf  that  makes  the  representation 
smaller  and  easier  to  understand. 
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1.  INTRODUCTION 
1.1.  SCOPE 

Thia  standard  •pacifies  a  syntax  for  taxt  messages  that  ara 
sent  among  computer  usars,  within  tha  framework  of  "alactronio 
■all”.  Tha  standard  supersedes  tha  one  specif lad  in  ARPANET 
Request  for  Comments  #733.  "Standard  for  tha  Format  of  ARPA  Net¬ 
work  Taxt  Massages". 

In  this  context,  aassagas  ara  viewed  as  having  an  envelope 
and  contents.  The  envelope  contains  whatever  information  is 
needed  to  accomplish  transmission  and  delivery.  The  contents 
compose  the  object  to  be  delivered  to  tha  recipient.  This  stan¬ 
dard  applies  only  to  the  format  and  some  of  the  semantics  of  mes¬ 
sage  contents.  It  contains  no  specification  of  the  information 
in  the  envelope. 

However,  some  massage  systems  may  use  information  from  the 
contents  to  create  the  envelope.  It  is  intended  that  this  stan¬ 
dard  facilitate  the  acquisition  of  such  information  by  programs. 

Some  message  systems  may  store  messages  in  formats  that 
differ  from  the  one  specified  in  this  standard.  This  specifica¬ 
tion  is  intended  strictly  as  a  definition  of  what  message  content 
format  is  to  be  passed  BETWEEN  hosts. 

Note:  This  standard  is  not  intended  to  dictate  the  internal  for¬ 
mats  used  by  sites,  the  specific  message  system  features 
that  they  are  expected  to  support,  or  any  of  the  charac¬ 
teristics  of  user  interface  programs  that  create  or  read 
messages. 

A  distinction  should  be  made  between  what  the  specification 
REQUIRES  and  what  it  ALLOWS.  Messages  can  be  made  complex  and 
rich  with  formally-structured  components  of  information  or  can  be 
kept  small  and  simple,  with  a  minimum  of  such  information.  Also, 
the  standard  simplifies  the  interpretation  of  differing  visual 
formats  in  messages;  only  the  visual  aspect  of  a  message  is 
affected  and  not  the  interpretation  of  information  within  it. 
Implementors  may  choose  to  retain  such  visual  distinctions. 

The  formal  definition  is  divided  into  four  levels.  The  bot¬ 
tom  level  describes  the  meta-notation  used  in  this  document.  The 
second  level  describes  basic  lexical  analyzers  that  feed  tokens 
to  highei — level  parsers.  Next  is  an  overall  specification  for 
messages;  it  permits  distinguishing  individual  fields.  Finally, 
there  is  definition  of  the  contents  of  several  si'uctured  fields. 
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1.2.  COMMUNICATION  FRAMEWORK 

Messages  consist  of  lines  of  text.  No  special  provisions 
aro  Made  for  encoding  drawings,  facsimile,  speech,  or  structured 
text.  No  significant  consideration  has  been  given  to  questions 
of  data  compression  or  to  transmission  and  storage  efficiency, 
and  the  standard  tends  to  be  free  with  the  number  of  bits  con¬ 
sumed.  For  example,  field  names  are  specified  as  free  text, 
rather  than  special  terse  codes. 

A  general  "memo"  framework  is  used.  That  is,  a  message  con¬ 
sists  of  some  information  in  a  rigid  format,  followed  by  the  main, 
part  of  the  message,  with  a  format  that  is  not  speoified  in  this 
document.  The  syntax  of  several  fields  of  the  rigidly-formated 
("headers")  section  is  defined  in  this  specification;  some  of 
these  fields  must  be  included  in  all  messages. 

v. 

The -syntax  that  distinguishes  bitween  header  fields  is 
specified  separately  from  the  internal  syntax  for  particular 
fields.  This  separation  is  intended  to  allow  simple  parsers  to 
operate  on  the  general  structure  of  messages,  without  concern  for 
the  detailed  structure  of  individual  header  fields.  Appendix  B 
is  provided  to  facilitate  construction  of  these  parsers. 

In  addition  to  the  fields  specified  in  this  document,  it  is 
expected  that  other  fields  will  gain  common  use.  As  necessary, 
the  specifications  for  these  "extension-fields"  will  be  published 
through  the  same  mechanism  used  to  publish  this  document.  Users 
may  also  wish  to  extend  the  set  of  fields  that  they  use 
privately.  Such  "user-def ined  fields"  are  permitted. 

The  framework  severely  constrains  document  tone  and  appear¬ 
ance  and  is  primarily  useful  for  most  incra-organization  communi¬ 
cations  and  well-structured  inter-organization  communication. 
It  also  can  be  used  for  some  types  of  inter-process  communica¬ 
tion,  such  as  simple  file  transfer  ard  remote  Job  entry.  A  more 
robust  framework  might  allow  for  multi-font,  multi-color,  multi¬ 
dimension  encoding  of  information.  A  less  robust  one,  as  is 
present  in  most  single-machine  message  systems,  would  more 
severely  constrain  the  ability  to  aad  fields  and  the  decision  to 
include  specific  fields.  In  contrast  with  paper-based  communica¬ 
tion.  it  is  interesting  to  note  that  the  RECEIVER  of  a  message 
cp  exercise  an  extraordinary  amount  of  control  over  the 
m«*(Jge's  appearance.  The  amount  o*  actual  control  available  to 
me  lge  receivers  is  contingent  upon  the  capabilities  of  their 
individual  message  systems. 
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2.  notatxonal  conventions 

Thia  specif lcation  uses  an  augnented  Backus-Naur  fora  (BNP) 
notation.  The  differences  from  standard  BNP  involve  naating  rules 
and  indicating  repetition  and  “local"  alternatives. 

2.1.  RULE  NAMING 

Angle  brackets  ”>”)  are  not  used,  in  general.  The 

naee  of  a  rule  is  simply  the  name  itself,  rather  than  "<na«e>". 
QuOtation-marks  enclose  literal  text  (which  may  be  upper  and/or 
lower  case).  Certain  basic  rules  are  in  uppercase,  such  as 
SPACE,  TAP,  CRLP ,  DIGIT,  ALPHA,  etc.  Angle  brackets  are  used  in 
rule  definitions,  and  in  the  rest  of  this  document,  whenever 
their  presence  will  facilitate  discerning  the  use  of  rule  names. 

2.2.  RULEl  /  RULE2 :  ALTERNATIVES 

Elements  separated  by  slash  (”/”)  are  alternatives.  There¬ 
fore  “foo  /  bar"  will  accept  foo  or  bar. 

2.3.  (RULEl  RULE2) :  LOCAL  ALTERNATIVES 

Elements  enclosed  in  parentheses  arw  treated  as  a  single 
element.  Thus,  "(elem  (foo  /  bar)  elem)"  allows  the  token 
sequences  "elem  foo  elem"  and  "elem  bar  elem”. 

2.4.  'RULE:  REPETITION 

The  character  "•"  preceding  an  element  Indicates  repetition. 
The  full  form  is: 


<l>r<m>element 

indicating  at  least  <1>  and  at  most  <m>  occurrences  of  element. 
Default  values  are  o  and  infinity  so  that  ”*(element)"  allows  any 
number,  including  zero;.  "l*element"  requires  at  least  one;  and 
"  1  »2elen.ent"  allows  one  or  two. 

2.5.  [RULE]:  OPTIONAL 

Square  brackets  enclose  optional  elements;  "[foo  barl"  is 
equivalent  to  "*l(foo  bar)". 

2.6.  NRULE :  SPECIFIC  REPETITION 

"<n>(element) *  is  equivalent  to  "<n>»<n>(element) " ;  that  is, 
exactly  <n>  occurrences  of  (element).  Thus  2DIGIT  is  a  2-digit 
number,  and  3ALPHA  is  a  string  c  three  alphabetic  characters. 
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2.7.  #RULE:  LISTS 

A  construct  *#"  la  defined,  aimilar  to  "•",  aa  follows: 

<l>#<m>elem«nt 

indicating  at  least  <1>  and  at  mt : t  <m>  elements,  each  separated 
by  one  or  mors  commas  (",").  This  makes  the  usual  form  of  lists 
very  easy;  a  rule  such  as  '(element  •  (",*  element))'  can  be  shown 
as  "l#element* .  Wherever  this  construct  is  used,  null  elements 
are  allowed,  but  do  not  contribute  to  the  count  of  elements 
present.  That  is,  "(element), , (element)"  is  permitted,  but 
counts  as  only  two  elements.  Therefore,  where  at  least  one  ele¬ 
ment  As  required,  at  least  one  non-null  element  must  be  present. 
Default  values  are  0  and  infinity  so  that  "#(element)"  allows  any 
number,  including  zero;  "i#element"  requires  at  least  one;  and 
"l#2elemwnt"  allows  one  or  two. 

2.8.  ;  COMMENTS 

A  semi-colon,  set  off  some  distance  to  the  right  of  rule 
text.  starts  a  comment  that  continues  to  the  end  of  line.  This 
is  a  simple  way  of  including  useful  notes  in  parallel  with  the 
specifications. 
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3.  LEXICAL  ANALYSIS  OF  MESSAGES 

3.1.  GENERAL  DESCRIPTION 

A  message  consists  of  header  fields  and.  optionally,  a  body. 
The  body  is  simply  a  sequence  of  lines  containing  ASCII  charac¬ 
ters.  it  is  separated  from  the  headers  by  a  null  line  (i.e.,  a 
line  with  nothing  preceding  the  CRLF). 

3.1.1.  LORO  HEADER  FIELDS 

Each  header  field  can  be  viewed  as  a  single,  logical  line  of 
ASCII  characters,  comprising  a  field-name  and  a  field-body. 
For  convenience,  the  field-body  portion  of  this  conceptual 
entity  can  be  split  into  a  multiple-line  representation;  this 
is  called  'folding*.  The  general  rule  is  that  wherever  there 
may  be  linear-white-space  (NOT  simply  LWSP-chars),  a  CRLF 
immediately  followed  by  AT  LEAST  one  LWSP-char  may  instead  be 
inserter’.  Thus,  the  single  line 

To:  "Joe  &  J.  Harvey"  <ddd  @Org>,  JJV  0  BBN 


can  be  represented  as: 

To:  "Joe  &  J.  Harvey"  <ddd  0  Org>, 

J JVbSBN 

and 


To:  "Joe  &  J. 

0BBN 


Harvey" 

<ddd®  Org>, 


JJV 


and 


To:  "Joe  & 

J.  Harvey"  <ddd  0  0-n>,  jjv  0  BBN 

The  process  of  movi...  from  this  folded  multiple-line 
representation  of  a  header  field  to  its  single  line  represen¬ 
tation  is  called  "unfolding”.  Unfolding  is  accomplished  by 
regarding  CRLF  immediately  followed  by  a  LWSP-char  as 
equivalent  to  the  LWSP-char. 

Note:  While  the  standard  permits  folding  wherever  linear- 
white-space  is  permitted,  it  is  recommended  that  struc¬ 
tured  fields,  such  as  those  containing  addresses,  limit 
folding  to  higher-level  syntactic  breaks.  For  address 
fields,  it  is  recommended  that  such  folding  occur 
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between  addresses,  after  the  separating  comma. 

3.1.2.  STRUCTURE  OF  HEADER  FIELDS 

Once  a  field  has  been  unfolded.  It  may  b<r  viewed  as  being  com¬ 
posed  of  a  field-name  followed  by  a  colon  followed  by  a 

field-body,  and  terminated  by  a  carriage-return/line-feed. 
The  field-name  must  be  composed  of  printable  ASCII  characters 
(i.e.,  characters  that  have  values  between  33.  and  126., 
decimal,  except  colon).  The  field-body  may  be  composed  of  any 
ASCII  characters,  except  CR  or  LF.  (While  CR  and/or  LF  may  be 
present  in  the  actual  text,  they  are  removed  by  the  action  of 
unfolding  the  field.) 

Certain  field-bodies  of  headers  may  be  interpreted  according 
to  an  internal  syntax  that  some  systems  may  wish  to  parse. 
These  fields  are  called  "structured  fields".  Examples 
include  fields  containing  dates  and  addresses.  Other  fields, 
such  as  "Subject"  and  "Comments" .  are  regarded  simply  as 
strings  of  text. 

Note:  Any  field  which  has  a  field-body  that  is  defined  as 
other  than  simply  <text>  is  to  be  treated  as  a  struc¬ 
tured  field. 

Field-names,  unstructured  field  bodies  and  structured 
field  bodies  each  are  scanned  by  their  own,  independent 
"lexical"  analyzers. 

3.1.3.  UNSTRUCTURED  FIELD  BODIES 

For  some  fields,  such  as  "Subject"  and  "Comments",  no  struc¬ 
turing  is  assumed,  and  they  are  treated  simply  as  <text>s,  as 
in  the  message  body.  Rules  of  folding  apply  to  these  fields, 
so  that  such  field  bodies  which  occupy  several  lines  must 
therefore  have  the  second  and  successive  lines  indented  by  at 
least  one  LWSP-char. 

3.1.4.  STRUCTURED  FIELD  BODIES 

To  aid  in  the  creation  and  reading  of  structured  fields,  the 
free  insertion  of  linear-white-space  'which  permits  folding 
by  inclusion  of  CRLFs)  is  allowed  between  lexical  tokens. 
Rather  than  obscuring  the  syntax  specifications  for  these 
structured  fields  with  explicit  syntax  for  this  lineai — white- 
space,  the  existence  oi  another  "lexical"  analyzer  is  assumed. 
This  analyzer  does  r  .t  apply  for  unstructured  field  bodies 
that  are  simply  strings  of  text,  as  described  above.  The 
analyzer  provider  an  interpretation  of  the  unfolded  text 
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composing  the  body  of  the  field  aa  a  aequenoe  of  lexical  *ym- 
bola. 

Theae  symbols  are: 

-  individual  apeoial  character* 

-  quoted-atringa 

-  domain-literals 

-  comment* 

-  atone 

The  firat  four  of  theae  aynbola  are  self-deliniting.  Atona 
are  not;  they  are  delieited  by  the  aalf-delimiting  aynbola  and 
by  iinear-white-apace.  For  the  purpoaea  of  regenerating 
aequencea  of  atona  and  quoted-atringa,  exactly  one  SPACE  ia 
assumed  to  exist,  and  should  be  used,  between  them.  (Also,  in 
the  "Clarifications"  section  on  "white  Space",  below,  note  the 
rules  about  treatment  uf  multiple  contiguous  LWSP-chors.) 

So,  for  example,  the  folded  body  of  an  address  field 

":sysmail"0  Some-Group.  Some-Org, 

Muhamred. (I  am  the  greatest)  All  e(the)Vegas.WBA 
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ia  analyzed  Into  the  following  laxleal  ayabola  and  typaa: 

:ayaaail  quotad  atring 

•  apaoial 

Some-Group  atoa 

apaeial 

Some-Org  atoa 

.  apaeial 

Muhammad  atom 

apaoial 

(Z  am  tha  graataat)  comment 
All  atoa 

•  atoa 

(tha)  comment 

vagaa  atom 

apaeial 

NBA  atom 

The  canonical  representationa  for  tha  data  in  thaaa  addraaaaa 
are  the  following  strings: 

”:sysmail* OSome-Gr ou  p . Some-Org 

and 

Muhammad . Alievegas . NBA 

Note:  For  purposes  of  display,  and  when  passing  such  struc¬ 
tured  information  to  other  systems,  such  as  mail  proto¬ 
col  services,  there  must  be  NO  lineai — white-space 
between  <word>s  that  are  separated  by  period  or 

at-sign  ("e")  and  exactly  one  SPACE  between  all  other 
<word>s.  Also,  headers  should  be  in  a  folded  form. 
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3.2.  HEADER  FIELD  DEFINITIONS 

These  rule*  show  a  flald  meta-syntax,  without  ragard  for  tha 
particular  typa  or  intarnal  syntax.  Thair  purposa  is  to  permit 
detection  of  fields;  also,  they  present  to  higher-level  parsers 
an  image  of  each  field  as  fitting  on  one  line. 

field  -  f ield-naae  (  field-body  )  CRLF 

field-name  -  l*<any  CHAR,  exeluding  CTLs,  SPACE,  and 

field-body  ■  field-body-contents 

(CRLF  LNSP-char  field-body 1 

f ield-body-contents  ■ 

<the  ASCII  characters  making  up  the  field-body,  as 
defined  in  the  following  sections,  and  consisting 
of  combinations  of  atom,  quoted-string,  and 
specials  tokens,  or  else  consisting  of  texts> 
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The  following  rules  are  used  to  define  an  underlying  lexical 
analyzer,  which  feeds  tokens  to  higher  level  parsers.  See  the 
ANSI  references,  in  the  Bibliography. 


;  (  Octal, 

Decimal. ) 

CHAR 

m 

<any  ASCII 

character> 

;  (  0-177, 

0.-127.) 

ALPHA 

m 

<any  ASCII 

alphabetic  character> 

;  (101-132. 

65.-  90.) 

{  (141-172, 

97.-122.) 

DIGIT 

m 

<any  ASCII 

decimal  digit> 

;  (  «0—  71. 

48.-  67.) 

CTL 

m 

<any  ASCII 

control 

5  (  0-  37. 

0.-  31.) 

character 

and  0EL> 

;  (  177. 

127.) 

CR 

m 

<ASCII  CR, 

carriage  return> 

;  (  16, 

13.) 

LF 

m 

<ASCII  LF, 

linefeed> 

;  (  12. 

10.) 

SPACE 

9 

<ASCZI  SP. 

sp&ce> 

:  (  40. 

32.) 

HTAB 

m 

<ASCII  HT, 

horizontal-tab> 

;  (  li. 

9.) 

<"> 

m 

< ascii  quote  ma.*k> 

;  (  42, 

34.) 

CRLF 

m 

CR  LF 

LWSP-char 

. 

SPACE  /  HTAB 

;  semantics 

■  SPACE 

linear-white-space  -  1*([CRLFJ  LNSP-char)  ;  semantics  «  SPACE 

;  CRLP  ->  folding 


specials  -  "("  /  ")"  /  "<"  /  ">"  /  "0*  ;  Must  be  in  quoted- 

/  /  "\"  /  <">  :  string,  to  use 

/  /  "["  /  "1"  ;  within  a  word. 

Jelimiters  -  specials  /  linear-white-space  /  comment 

text  »  <any  CHAR,  including  bare  ;  ■>  atoms,  specials, 

CR  S  bare  LF,  but  NOT  ;  comments  and 

including  CRLF>  ;  quoted-strings  are 

;  HOT  recognized. 

atom  *  1 »<any  char  except  specials,  SPACE  and  CTLs> 

quoted-string  =  <">  «■  (qtext/quoted-pair )  <">;  Regular  qtext  or 

;  quoted  chars. 

qtext  -  <any  CHAR  excepting  <">,  ;  ■>  may  be  folded 

"\"  A  CR,  and  including 
linear-white-space> 

domain-literal  *  "["  *(dtext  /  quoted-pair)  "]" 
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dtext 

m 

<any  CHAR  excluding 
•}■.  -\"  A  CR,  A  including 
1 inear-wh i te-space> 

• 

• 

■>  may  be  folded 

comment 

m 

*(■  • (ctext  /  quoted-pair  / 

comment)  “)• 

ctext 

m 

<any  CHAR  excluding  •(", 

*\*  A  CR,  A  including 
linear-white-space> 

• 

■*>  may  be  folded 

quoted-pair 

m 

•\"  CHAR 

• 

• 

may  quote  any  char 

phrase 

- 

i'word 

• 

• 

Sequence  of  words 

word 

- 

atom  /  quoted-string 

3.4.  n.ARZFXCATZONS 
3.4.1.  QUOTING 

Some  characters  are  reserved  for  special  interpretation,  such 
as  delimiting  lexical  tokens.  To  permit  use  of  these  charac¬ 
ters  as  uninterpreted  data,  a  quoting  mechanism  is  provided. 
To  quote  a  character,  precede  It  with  a  backslash  ("\"). 

This  mechanism  is  not  fully  general.  Characters  may  be  qu.  :'d 
only  within  a  subset  of  the  lexical  constructs.  In  particu¬ 
lar,  quoting  is  limited  to  use  within: 

-  quoted-string 

-  domain-literal 

-  comment 

Within  these  constructs,  quoting  is  REQUIRED  for  CR  and  "\" 
and  for  the  character (*)  that  delimit  the  token  (e.g.,  ”(”  and 
")"  for  a  comment).  However,  quoting  is  PERMITTED  for  any 
character . 

Note:  In  particular,  quoting  is  NOT  permitted  within  atoms. 

For  example  when  the  local-part  of  an  addi — spec  must 
contain  a  special  character,  a  quoted  string  must  be 
used.  Therefore,  a  specification  such  as: 

Full\  NamedDomain 

is  not  legal  and  must  be  specified  as: 

"Full  Name’ODomain 
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3.4.2.  WHITE  SPACE 

Note:  in  structured  field  bodies,  multiple  linear  space  ASCII 
characters  (namely  HTASs  and  SPACES)  are  treated  as 
single  spaces  and  aay  freely  surround  any  symbol.  In 
all  header  fields,  the  only  place  in  which  at  least  one 
LWSP-char  is  REQUIRED  is  at  the  beginning  of  continua¬ 
tion  lines  in  a  folded  field. 

when  passing  text  to  processes  that  do  not  interpret  taxt 
according  to  this  standard  (e.g.,  mail  protocol  servers),  then 
no  linear-white-space  characters  should  occur  between  a  period 
(*.")  or  at-sign  ("0")  and  a  <word>.  Exactly  ONE  SPACE  should 
be  used  in  place  of  arbitrary  linear-white-space  and  comment 
sequences. 

Note:  Within  systems  conforming  to  this  standard,  wherever  a 
member  of  the  list  of  delimiters  is  allowed,  LWSP-chars 
may  also  occur  before  and/or  after  it. 

Writers  of  mail-sending  (i.e.,  header-generating)  programs 
should  realise  that  there  is  no  network-wide  definition  of  the 
effect  of  ASCII  HT  (horizontal-tab)  characters  on  the  appear¬ 
ance  of  text  at  another  network  host;  therefore,  the  use  of 
tabs  in  message  headers,  though  permitted,  is  discouraged. 

3.4.3.  COMMENTS 

A  comment  is  a  set  of  ASCII  characters,  which  is  enclosed  in 
matching  parentheses  and  which  is  not  within  a  quoted-string 
The  comment  construct  permits  message  originators  to  add  text 
which  will  be  useful  for  human  readers,  but  which  will  be 
ignored  by  the  formal  semantics.  Comments  should  be  retained 
while  the  message  is  subject  to  interpretation  according  to 
this  standard.  However,  comments  must  NOT  be  included  in 
other  cases,  such  as  during  protocol  exchanges  with  mail 
servers . 

Comments  ne3t,  so  that  if  an  unquoted  left  parenthesis  occurs 
in  a  comment  string,  there  must  also  be  a  matching  right 
parenthesis,  when  a  comment  acts  as  the  delimiter  between  a 
sequence  of  two  lexical  symbols,  such  as  two  atoms,  it  is  lex¬ 
ically  equivalent  with  a  single  SPACE,  for  the  purposes  of 
regenerating  the  sequence,  such  as  when  passing  the  sequence 
onto  a  mail  protocol  server.  Comments  are  detected  as  such 
only  within  field-bodies  of  structured  fields. 

If  a  comment  is  to  be  "folded"  onto  multiple  lines,  then  the 
syntax  for  folding  must  be  adhered  to.  (See  the  "Lexical 
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Analysis  of  Massages"  section  on  "Folding  Long  Header  Fields" 
above,  and  the  section  on  "Case  independence"  below.)  Note 
that  the  official  semantics  therefore  do  not  "see"  any 
unquoted  CRLFs  that  are  in  comments,  although  particular  pars¬ 
ing  programs  may  wish  to  note  their  presence.  For  these  pro¬ 
grams.  it  would  be  reasonable  to  Interpret  a  "CRLF  LWSP-char" 
as  being  a  CRLF  that  is  part  of  the  comment;  i.e.,  the  CRLF  is 
kept  and  the  LWSP-char  is  discarded.  Quoted  CRLFs  (i.e.,  a 
backslash  followed  by  a  CR  followed  by  a  LF)  still  must  be 
followed  by  at  least  one  LWSP-char. 

3.4.4.  DELIMITING  AND  QUOTING  CHARACTERS 

The  quote  character  (backslash)  and  characters  that  delimit 
syntactic  units  are  not,  generally,  to  be  taken  as  data  that 
are  part  of  the  delimited  or  quoted  unit(s).  In  particular, 
the  quotation-marks  ^hat  define  a  quoted-string,  the 
parentheses  that  define  a  comment  and  the  backslash  that 
quotes  a  following  character  are  NOT  part  of  the  quoted- 
string,  comment  or  quoted  character.  A  quotation-mark  that  is. 
to  be  part  of  a  quoted-string,  a  parenthesis  that  is  to  be 
part  of  a  comment  and  a  backslash  that  is  to  be  part  of  either 
must  each  be  preceded  by  the  quote-character  backslash  ("\"). 
Note  that  the  syntax  allows  any  character  to  be  quoted  within 
a  quoted-string  or  comment;  however  only  certain  characters 
must  be  quoted  to  be  included  as  data.  These  characters  are 
the  ones  that  are  not  part  of  the  alternate  text  group  (i.e., 
ctext  or  qtext) . 

The  one  exception  to  this  rule  is  that  a  single  SPACE  is 
assumed  to  exist  between  contiguous  words  in  a  phrase,  and 
this  interpretation  is  independent  of  the  actual  number  of 
LWSP-char s  that  the  creator  places  between  the  words.  To 
include  more  than  one  SPACE,  the  creator  must  make  the  LWSP- 
chars  be  part  of  a  quoted-string. 

Quotation  marks  that  delimit  a  quoted  string  and  backslashes 
that  quote  the  following  character  should  NOT  accompany  the 
quoted-string  when  the  string  is  passed  to  processes  that  do 
not  interpret  data  according  to  this  specification  (e.g.,  mail 
protocol  servers) . 

3.4.5.  QUOTED-STRINGS 

Where  permitted  (i.e.,  in  words  in  structured  fields)  quoted- 
strings  are  treated  as  a  single  symbol.  That  is,  a  quoted- 
string  is  equivalent  to  an  atom,  syntactically.  If  a  quoted- 
string  is  to  be  "folded"  onto  multiple  lines,  then  the  syntax 
for  folding  must  be  adhered  to.  (See  the  "Lexical  Analysis  of 
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Massages"  section  on  "Folding  Long  Header  Fields"  above,  and 
the  section  on  "Case  Independence"  below.)  Therefore,  the 
official  semantics  do  not  "see"  any  bare  CRLFs  that  are  in 
quoted-strings;  however  particular  parsing  programs  may  wish 
to  note  their  presence.  ro r  such  programs,  it  would  be  rea¬ 
sonable  to  interpret  a  "CRLF  LftSP-char"  as  being  a  CRLF  which 
is  part  of  the  quoted-string;  i.e.,  the  CRLF  is  kept  and  the 
LWSP-char  is  discarded.  Quoted  CRLFs  (i.e.,  a  backslash  fol¬ 
lowed  by  a  CR  followed  by  a  LF)  are  also  subject  to  rules  of 
folding,  but  the  presence  of  the  quoting  character  (backslash) 
explicitly  indicates  that  the  CRLF  is  data  to  the  quoted 
string.  Stripping  off  the  first  following  Lt,5P-char  is  also 
appropriate  when  parsing  quoted  CRLFs. 

3.4.6.  BRACKETING  CHARACTERS 

There  is  one  type  of  bracket  which  must  occur  in  matched  pairs 
and  may  have  pairs  nested  within  each  other: 

o  Parentheses  ("("  and  ")")  are  used  to  indicate  com¬ 
ments. 

There  are  three  types  of  brackets  which  must  occur  in  matched 
pairs,  and  which  may  NOT  be  nested: 

o  Colon/semi-colon  (":"  and  ";")  are  used  in  address 
specifications  to  Indicate  that  the  included  list  of 
addresses  are  to  be  treated  as  a  group. 

o  Angle  brackets  ("<"  and  ">")  are  generally  used  to 
indicate  the  presence  of  a  one  machine-usable  refer¬ 
ence  (e.g.,  delimiting  mailboxes),  possibly  including 
source-routing  to  the  machine. 

o  Square  brackets  ("["  and  "]")  are  U3ed  to  indicate  the 
presence  of  a  domain-literal,  which  the  appropriate 
name-domain  is  to  use  directly,  bypassing  normal 
name-resolution  mechanisms. 

3.4.7.  CASE  INDEPENDENCE 

Except  as  noted,  alphabetic  strings  may  be  represented  in  any 
combination  of  upper  and  lo».er  case.  The  only  syntactic  units 
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which  requires  preservation  of  ease  information  are: 

-  text 

-  qtext 

-  dtext 

-  etext 

-  quoted-pair 

-  local-part,  except  "Postmaster" 

When  matching  any  other  syntactio  unit,  cose  is  to  be  ignored, 
for  example,  the  field-names  "From",  "FROM",  "from",  and  even 
"FroM"  are  semantically  equal  and  should  all  be  treated  ident¬ 
ically. 

When  generating  these  units,  any  mix  of  upper  and  loner  case 
alphabetic  characters  may  be  used.  The  case  shown  in  this 
specification  is  suggested  for  message-creating  processes. 

Note:  The  reserved  local-part  address  unit,  "Postmaster",  is 
an  exception.  When  the  value  "Postmaster"  is  being 
interpreted,  it  must  be  accepted  in  any  mixture  of 
case,  including  "POSTMASTER”,  and  "postmaster”. 

3.4.8.  FOLDING  LONG  HEADER  FIELDS 

Each  header  field  may  b;  represented  on  exactly  one  line  con¬ 
sisting  of  the  name  of  the  field  and  its  body,  and  terminated 
by  a  CRLF;  this  is  what  the  parser  sees.  For  readability,  the 
field-body  portion  of  long  header  fields  may  be  "folded"  onto 
multiple  lines  of  the  actual  field.  "Long"  is  commonly  inter¬ 
preted  to  mean  greater  than  65  or  72  characters.  The  former 
length  selves  as  a  limit,  when  the  message  is  to  be  viewed  on 
most  simple  terminals  which  use  simple  display  software;  how¬ 
ever,  the  limit  is  not  imposed  by  this  standard. 

Note:  Some  display  software  often  can  selectively  fold  lines, 
to  suit  the  display  terminal.  In  such  cases,  sendei — 
provided  folding  can  interfere  with  the  display 
software. 

3.4.9.  BACKSPACE  CHARACTERS 

ASCII  BS  characters  (Backspace,  decimal  8)  may  be  included  in 
texts  and  quoted-strings  to  effect  ever  striking.  However,  any 
use  of  backspaces  which  effects  an  ove>  strike  to  the  left  of 
the  beginning  of  the  text  or  quoted-string  is  prohibited. 
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3.4. 10.  NETWORK-SPECIFIC  TRANSFORMATIONS 

During  transmission  through  heterogeneous  networks,  it  may  be 
necessary  to  force  data  to  conform  to  a  network's  local  con¬ 
ventions.  For  example,  it  may  be  required  that  a  CR  be  fol¬ 
lowed  either  by  LF,  making  a  CRLF ,  or  by  <null>,  if  the  CR  is 
to  stand  alone) .  Such  transformations  are  reversed,  when  the 
message  exits  that  network. 

When  crossing  network  boundaries,  the  message  should  be 
treated  as  passing  through  two  modules.  It  will  enter  the 
first  module  containing  whatever  network-specif ic  transforma¬ 
tions  that  were  necessary  to  permit  migration  through  the 
"current"  network.  It  then  passes  through  the  modules: 


Transformation  Reversal 


"*'v 


The  "current”  network's  idiosyncracies  are  removed  and 
the  message  is  returned  to  the  canonical  form  speci¬ 
fied  in  this  standard. 


Transformation 

The  "next"  network's  local  idiosyncracies  are 
on  the  message. 


imposed 


O 


From 

Net-A 


Remove  Net-A 
idiosyncracies 


\/ 

Conformance 
with  standard 

I  I 
\/ 

Impose  Nec-B  | 
idiosyncracies  | 


«n> 


To 

Net-B 


0 
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4.  MESSAGE  SPECIFICATION 
4.1.  SYNTAX 

Note:  Due  to  an  artifact  of  the  notational  conventione.  the  eyn- 
tax  indicatee  that,  when  preeent.  some  fielde.  must  be  in 
a  particular  order.  Header  fielde  are  NOT  required  to 
occur  in  any  particular  order,  except  that  the  message 
body  muet  occur  AFTER  the  headere.  It  ie  recommended 
that,  if  preeent,  headere  be  cent  in  the  order  "Return- 
Path",  "Received".  "Date",  "From",  "Subject"’,  "Sender", 
"To",  "cc",  etc. 

Thie  specification  permita  multiple  oc  >urrencea  of  moat 
fielde.  Except  ae  noted,  their  interpretation  ie  not 
specified  herel,  and  their  uae  ie  discouraged. 


The  following  eyntax  for  the  bodiea  of  varioua  fielde  ehould 
be  thought  of  aa  describing  each  field  body  as  a  single  lung 
string  (or  line).  The  "Lexical  Analysis  of  Message"  section  on 
"Loog  Header  Fields",  above,  indicates  how  such  long  strings  can 
be  represented  on  more  than  one  line  in  the  actual  transmitted 
message, 


message 

s 

fields  •(  CRLF 

•text  ) 

» 

Everything  after 

* 

first  null  line 

♦ 

is  message  body 

fields 

as 

dates 

* 

Creation  time. 

source 

• 

* 

author  id  &  one 

l*destination 

• 

address  required 

•optional-field 

• 

others  optional 

source 

[  trace  ] 

V 

net  traversals 

originator 

» 

original  mail 

[  resent  ] 

* 

forwarded 

trace 

return 

» 

path  to  sender 

l*received 

• 

t 

receipt  tags 

return 

» 

"Return-path" 

> oute-addr 

• 

* 

return  address 

received 

. 

"Received" 

N  ,  ft 

• 

one  per  relay 

["from" 

["by" 

["via" 

•("with" 

["id" 

["for" 


domain] 

domain] 

atom] 

atom) 

msg-id] 

addr-spec] 


sending  host 
receiving  host 
physical  path 
link/mail  protocol 
receiver  msg  id 
initial  form 
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•  e  • 

• 

date-tiae 

• 

9 

time  received 

originator 

authentic 

9 

authenticated  addr 

I  "RepJy-To' 

":"  Ifaddress] 

) 

authentic 

•From" 

mailbox 

• 

t 

Single  author 

/ 

(  "Sender" 

*:"  mailbox 

9 

Actual  subenittor 

"From" 

":"  lfmailbox) 

(, 

Multiple  authors 

• 

or  not  sender 

resent  m  resent-authentic 

l  "Resent-Reply-To"  lfaddress]  ) 


resent-authentic  m 

m  "Resent-From" 

/  (  "Resent-Sender" 
"Resent- From" 


"s"  mailbox 
mailbox 

•:*  l#mailbcx  ) 


dates 


orig-date 
[  resent-date  ] 


Original 

Forwarded 


orig-date  ■  “Date" 


"s"  date-time 


resent-date 


"Reser.t-Oate" 


date-time 


destination  - 
/ 
/ 
/ 
/ 
/ 


-TO" 

"Resent-To" 

"cc" 

"Resent-cc" 

“bcc" 

"Resent-bcc" 


lfaddress 
lfaddress 
lfaddress 
lfaddress 
faddre&s 
- :  -  faddress 


Primary 
Secondary 
Blind  carbon 


optional-field  ■ 

/  "Message-ID”  • 

/  "Resent-Message-ID"  - 

/  "In-Reply-To"  - 

/  "References-  * 

/  "Keywords"  - 

/  "Subject" 

/  "Comments"  " 

/  "Encrypted"  " 

/  extension-f ieJ d 

/  user-def ined-f ield 


rig-id 

msg-id 

•(phrase  /  msg-id) 
•(phrase  /  msg-id) 
fphrase 
•text 
•  text 
l#2word 


;  To  bo  defined 
;  May  be  pre-empted 


msg-id 


"<"  addr-spec  ">" 


Unique  message  id 
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axtanaion-f laid  ■ 

<Any  Mold  which  la  dofinod  In  a  document 
published  aa  a  formal  oxtonaion  to  thia 
apoclf ication;  nona  will  have  nawoa  boginning 
with  tho  atrlng  "X-"> 

uaor-dof inod-f lold  - 

<Any  field  which  haa  not  be'n  dofinod 
In  thla  opacification  or  publlahod  aa  an 
oxtonaion  to  thla  opacification;  nawoa  for 
auch  flolda  wuat  bo  unique  and  nay  bo 
pre-empted  by  publlahod  oxtonalona> 

4.2.  FORWAROXNG 

Sowo  ayatona  pornlt  nail  rociplonta  to  forward  a  neaaage, 
retaining  tho  original  hoadora.  by  adding  a owe  now  flolda.  Thia 
atandard  aupporta  auch  a  aarvice.  through  tho  "Resent-"  prefix  to 
field  nanoa. 

whenever  the  atrlng  "Resent-*  begina  a  field  nano,  tho  field 
haa  tho  aano  aenantlca  aa  a  fiald  whoao  nano  dooa  not  havo  tho 

prefix.  However,  the  neaaage  la  aaauned  to  havo  been  forwarded 
by  an  original  recipient  who  attached  tho  "Reaent-”  field.  Thia 
new  field  ia  treated  aa  being  noro  recent  than  tho  equivalent, 
original  field.  For  example,  tho  "Reaent-Fron" ,  indicate*  the 
person  that  forwarded  tho  neaaage,  whoreaa  tho  "Fron*  field  indi¬ 
cate*  the  original  author. 

Uao  of  auch  precedence  infornatlon  depend*  upon  partici¬ 
pant*'  communication  need*.  For  example,  thia  atandard  doea  not 
dictate  when  a  "Reaent-Fron: "  address  should  receive  replies,  in 
lieu  of  sending  then  to  the  "From:"  address. 

Note:  Xn  general,  the  "Resent-”  fields  should  be  treated  as  con¬ 
taining  a  set  of  information  that  is  independent  of  the 
set  of  original  field*,  information  for  on*  set  should 
not  automatically  be  taken  fron  the  other.  The  interpre¬ 
tation  of  multiple  "Resent-"  fields,  of  the  sane  type,  is 
undefined. 

In  the  remainder  of  this  specification,  occurrence  of  legal 
"Resent-"  fields  are  treated  identically  with  the  occurrence  of 
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fialda  whose  naaaa  do  not  eontain  this  profix. 

4.3.  TRACE  FIELDS 

Traea  inforaation  is  usad  to  provida  an  audit  trail  of  mes¬ 
sage  handling.  xn  addition,  it  indieataa  a  rout*  book  to  the 
•andar  of  tha  message. 

Tha  liat  of  known  "via"  and  "with*  valuas  ara  ragiatarad 
with  tha  Natwork  Xnforaation  Can tar,  SRX  Xntarnational.  Manlo 
Park,  California. 

4.3.1.  RETURN-PATH 

This  fiald  is  addad  by  tha  final  transport  systaa  that 
dalivars  tha  massaga  to  its  recipient.  Tha  fiald  is  intandad 
to  eontain  daf initiva  inforaation  about  tha  addrass  and  routo 
back  to  tha  aassaga's  originator. 

Nota:  Tha  "Raply-To"  fiald  is  addad  by  tha  originator  and 
sarvas  to  direct  raplias,  whereas  the  "Return-Path” 
fiald  is  usad  to  identify  a  path  back  to  tha  origina¬ 
tor  . 

While  tha  syntax  indicates  that  a  route  specification  is 
optional,  every  attempt  should  be  made  to  provida  that  infor¬ 
mation  in  this  fiald. 

4.3.2.  RECEIVED 

A  copy  of  this  field  is  addad  by  each  transport  service  that 
relays  tha  massaga.  Tha  information  in  tha  fiald  can  be  quite 
useful  for  tracing  transport  problems. 

Tha  names  of  the  sanding  and  receiving  hosts  and  time-of- 
racalpt  may  be  specified.  Tha  "via*  parameter  may  be  used,  to 
indicate  what  physical  mechanism  the  message  was  sent  over, 
such  as  Arpanet  or  Phonenet,  and  tha  "with"  parameter  may  be 
used  to  indicate  the  mail-,  or  connection-,  level  protocol 
that  was  used,  such  as  the  SMTP  mail  protocol,  or  X.25  tran¬ 
sport  protocol. 

Note:  Several  "with"  parameters  may  be  included,  to  fully 
specify  the  set  of  protocols  that  were  used. 

Some  transport  services  queue  mail;  the  internal  massage  iden¬ 
tifier  that  is  assigned  to  the  message  may  be  noted,  using  the 
"id"  parameter.  When  the  sending  host  uses  a  destination 
address  specification  that  the  receiving  host  reinterprets,  by 
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axpanslon  or  transformation,  tha  receiving  host  may  wish  to 
racord  th«*  original  spaeif ieation,  using  tha  "for"  paramatar. 
For  axampla,  whan  a  copy  of  mail  is  sant  to  tha  maabar  of  a 
distribution  list,  this  paramatar  may  be  used  to  racord  tha 
original  addrass  that  was  used  to  spacify  tha  list. 

4.4.  ORZOZNATOR  FIELDS 

Tha  standard  allows  only  a  subsat  of  tha  combinations  possi¬ 
ble  with  tha  From,  Sender.  Reply-To,  Resant-From,  Resent-Sender , 

and  Resnnt-Reply-To  fields.  Tha  limitation  is  intentional. 

4.4.1.  FROM  /  RESENT— FROM 

This  field  contains  the  identity  of  tha  person(s)  who  wished 
this  massage  to  be  sant.  The  message-creation  process  should 
default  this  field  to  ba  a  single,  authenticated  machine 
address,  indicating  the  AGENT  (person,  system  or  process) 
entering  the  message,  if  this  is  not  done,  the  "Sender"  field 
MUST  ba  present,  if  tha  "From"  field  IS  defaulted  this  way, 
tha  "Sander"  field  is  optional  and  is  redundant  with  tha 
"From”  field.  Zn  all  cases,  addresses  in  the  "From"  field 
must  be  machine-usable  (addr-specs)  and  may  not  contain  named 
lists  (groups). 

4.4.2.  SENDER  /  RESENT-SENDER 

This  field  contains  the  authenticated  identity  of  the  agent 
(person,  system  or  process)  that  sends  the  message.  Zt  is 
intended  for  use  when  the  sender  is  not  the  author  of  the  mes¬ 
sage,  or  to  indicate  who  among  a  group  of  authors  actually 
sent  the  message.  Zf  the  contents  of  the  "Sender"  field  would 
be  completely  redundant  with  the  "From"  field,  then  tho 
"Sender”  field  need  not  be  present  and  its  use  is  discouraged 
(though  still  legal).  In  particular,  the  "Sender”  field  must 
be  present  if  it  is  NOT  the  same  as  the  "From"  Field. 

The  Sender  mailbox  specification  includes  a  word  sequence 
which  must  correspond  to  a  specific  agent  (i.e.,  a  human  user 
or  a  computer  program)  rather  than  a  standard  address.  This 
indicates  the  expectation  that  the  field  will  identify  the 
single  AGENT  (person,  system,  or  process)  responsible  for 
sending  the  mail  and  not  simply  include  the  name  of  a  mailbox 
from  which  the  mail  was  sent.  For  example  in  the  case  of  a 
shared  login  name,  the  name,  by  itself,  would  not  be  adequate. 
The  local-part  address  unit,  which  refers  to  this  agent,  is 
expected  to  be  a  computer  system  term,  and  not  (for  example)  a 
generalized  person  reference  which  can  be  used  outside  the 
network  text  message  context. 
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Sinea  the  critical  function  aarvad  by  the  "Sender"  fiald  la 
idantif ication  of  tha  agant  responsible  for  sanding  aail  and 
ainca  computer  programs  cannot  ba  held  accountable  for  their 
behavior,  it  is  strongly  recommended  that  whan  a  computer  pro¬ 
gram  generates  a  massage,  tha  human  mho  is  responsible  for 
that  program  ba  referenced  as  part  of  the  "Sender"  field  mail¬ 
box  specification. 

4.4.3.  REPLY— TO  /  RESENT-REPLY-TO 

This  field  provides  a  general  mechanism  for  indicating  any 
mailbox(es)  to  which  responses  are  to  be  sent.  Three  typical 
uses  for  this  feature  can  be  distinguished.  Xn  the  first 
case,  the  author (s)  may  not  have  regular  machine-baced  mail¬ 
boxes  and  therefore  wish(es)  to  indicate  an  alternate  machine 
address.  in  the  second  case,  an  author  may  wish  additional 
persons  to  be  made  aware  of,  or  responsible  for,  replies.  A 
somewhat  different  use  may  be  of  some  help  to  "text  message 
teleconferencing"  groups  equipped  with  automatic  distribution 
services:  include  the  address  that  service  in  the  "Reply- 

To"  field  of  all  messages  submitted  to  the  teleconference; 
then  participants  can  "reply”  to  conference  submissions  to 
guarantee  the  correct  distribution  of  any  submission  of  their 
own , 

Note:  The  "Return-Path"  field  is  added  by  the  mail  transport 
service,  at  the  time  of  final  deliver,  xt  is  intendod 
to  identify  a  path  back  to  the  orginator  of  the  mes¬ 
sage.  The  "Reply-To"  field  is  added  by  the  message 
originator  and  is  intended  to  direct  replies. 

4.4.4.  AUTOMATIC  USE  OF  FROM  /  SENDER  /  REPLY-TO 

For  systems  which  automatically  generate  address  lists  for 
replies  to  messages,  the  following  recommendations  are  made: 

o  The  "Sender"  field  mailbox  should  be  sent  notices  of 
any  problems  in  transport  or  delivery  of  the  original 
messages,  if  there  is  no  "Sender"  field,  then  the 
"From”  field  mailbox  should  be  used. 

o  The  "Sender"  field  mailbox  should  NEVER  be  used 
automatically,  in  a  recipient's  reply  message. 

o  If  the  "Reply-To”  field  exists,  then  the  reply  should 
go  to  the  addresses  indicated  in  that  field  and  not  to 
the  address(es)  indicated  in  the  "From"  field. 
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o  Zf  there  la  a  "Proa"  flald,  but  no  "Reply-To"  fiald. 
the  raply  should  ba  sant  to  tha  addraas(aa)  indlcatad 
in  tha  “Proa"  flald. 

Soaatiaaa.  a  racipiant  aay  actually  wish  to  eoaaunioata  with 
tha  parson  that  initiatad  tha  message  transfar.  in  sueh 
casas.  it  is  raasonabla  to  usa  tha  "Sender*  addrass. 

This  raeoaaandation  is  intended  only  for  autoaatad  usa  of 
criginator-f ialds  and  is  not  intandad  to  suggast  that  raplias 
aay  not  also  ba  sant  to  othar  racipiants  of  aassagas.  it  is 
up  to  tha  raspactiva  mail-handling  prograas  to  daoida  what 
additional  faoilitias  will  ba  providad. 

Examples  ara  providad  in  Appandix  A. 

4.5.  RECEIVER  PZELOS 

4.5.1.  TO  /  AESENT-TO 

This  fiald  contains  tha  ldantity  of  tha  priaary  racipiants  of 
tha  nassaga. 

4.5.2.  CC  /  RESENT-CC 

This  fiald  contains  tha  identity  of  tha  secondary  (informa- 
tionsl)  recipients  of  tha  massage. 

4.5.3.  BCC  /  RESENT— BCC 

This  field  contains  tha  identity  of  additional  recipients  of 
the  message.  The  contents  of  this  field  are  not  included  in 
copies  of  the  message  sant  to  the  primary  and  secondary  reci¬ 
pients.  Some  systems  may  choose  to  include  the  text  of  the 
"Bcc*  field  only  in  the  author(s)'s  copy,  while  others  aay 
also  include  it  in  the  text  sent  to  all  those  indicated  in  the 
"Bcc"  list. 

4.8.  REFERENCE  FIELDS 

4.8.1.  MESSAGE— ID  /  RESENT— MESSAGE— ID 

This  field  contains  a  unique  identifier  (the  local— part 
address  unit'  ^ich  refers  to  this  version  of  THIS  message^ 
The  uniqueners  of  ihe  message  identifier  is  guaranteed  by  the 
host  which  generates  it.  This  identifier  is  intended  to  be 
machine  readable  and  not  necessarily  meaningful  to  humans.  A 
message  ident  fier  pertains  to  exactly  one  instantiation  of  a 
particular  message;  subsequent  revisions  to  the  message  should 
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each  racaiva  naw  message  idantifiara. 

4. a. a.  xn-replv-to 

Tha  eontants  -of  this  fiald  idantify  pravlous  correspon- 
danoa  which  this  aassaga  answers.  Note  that  if  message  iden¬ 
tifiers  are  used  in  this  field,  they  wust  use  tha  meg-id 
specification  foraat. 

4.6.3.  REFERENCES 

The  contents  of  this  fiald  identify  other  correspondence 
which  this  aassaga  references.  Note  that  if  Message  identif¬ 
iers  are  used,  they  Must  use  the  asg-id  specification  foraat. 

4.6.4.  KEYWORDS 

This  field  contains  keywords  or  phrases,  separated  by 
COMMaS . 

4.7.  OTHER  FIELDS 

4.7.1.  SUBJECT 

This  is  intended  to  provide  a  summary,  or  indicate  the 
nature,  of  the  Message. 

4.7.2.  COMMENTS 

Peraits  adding  text  comments  onto  the  message  without 
disturbing  the  contents  of  the  message's  body. 

4.7.3.  ENCRYPTED 

Sometimes,  data  encryption  is  used  to  increase  the 
privacy  of  message  contents.  If  the  body  of  a  message  has 
been  encrypted,  to  keep  its  contents  private,  the  "Encrypted" 
field  can  be  used  to  note  the  fact  and  to  indicate  the  nature 
of  the  encryption.  The  first  <word>  parameter  indicates  the 
software  used  to  encrypt  the  body,  and  the  second,  optional 
<word>  is  intended  to  aid  the  recipient  in  selecting  the 
proper  decryption  key.  This  code  word  may  be  viewed  as  an 
index  to  a  table  of  keys  held  by  the  recipient. 

Note:  Unfortunately,  headers  must  contain  envelope,  as  well 
as  contents,  information.  Consequently,  it  is  neces¬ 
sary  that  they  remain  unencrypted,  so  that  mail  tran¬ 
sport  services  may  access  them.  Since  names. 
Addresses,  and  "Subject"  field  contents  may  contain 
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aanaitiva  information,  this  roquiramant  limit*  total 
ma**aga  privacy. 

Names  of  ancryption  software  ara  ragistarad  with  tha  Nat- 
work  Information  Cantor,  SRZ  Zntarnational,  Menlo  Park,  Cali¬ 
fornia. 

4.7.4.  EXTENSION— FIELD 

A  limitad  number  of  common  fiald*  hava  baan  dafinad  in 
thi*  document.  A*  network  mail  roquiramant*  dictate,  addi¬ 
tional  fiald*  may  be  standardized.  To  provide  user-defined 
field*  with  a  measure  of  safety,  in  nama  selection,  such 
axtansion-f iolds  will  never  hava  names  that  begin  with  tha 
string  "X-*. 

Names  of  Extension-fields  ara  registered  with  the  Network 
Information  Center,  SRZ  International,  Menlo  Park,  California. 

4.7.5.  USER-DEFINED— FIELD 

Individual  users  of  natwork  mail  are  fra*  to  define  and 
use  additional  header  fields.  Such  fields  must  have  names 
which  ara  not  already  used  in  the  current  specification  or  in 
any  definitions  of  extension-fields,  and  the  overall  syntax  of 
these  user-def ined-f ields  mu»t  conform  to  this  specification's 
rules  for  delimiting  and  folding  fields.  Due  to  the 
extension-field  publishing  process,  the  name  of  a  user- 
def  ined-f  ield  may  be  pre-empted 

Mote:  The  prefatory  string  "X-"  will  never  be  used  in  the 
names  of  Extension-fields.  This  provides  user-defined 
fields  withfa  protected  set  of  names. 
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S.l.  SYNTAX 


date-time 

“ 

{  day 

"  ]  date  time 

.  :  dd  mm  yy 
;  hh:ma:ss  zzz 

day 

m 

/ 

•Mon"  / 
"Fri"  / 

"Tue"  /  "wed" 
"Sat"  /  "Sun- 

/  "Thu" 

date 

m 

1*2DIGIT 

month  2DIQIT 

;  day  month  year 
;  a.g.  20  Jun  82 

month 

m 

•Jan"  / 

"Feb"  /  "Mar" 

/  "Apr" 

/ 

•May*  / 

"Jun"  /  "Jul" 

/  "Aug" 

/ 

•Sep"  / 

"Oct"  /  "Nov" 

/  "Dec" 

time 

• 

hour  zone 

;  ANSI  and  Military 

hour 

m 

20IGIT  • 

:"  2DIGIT  I"s"  20IGITJ 

;  00: 00: OC  -  23:59:59 

zone 

m 

"UT"  / 

"GMT" 

;  Universal  Time 
;  North  American  :  UT 

/ 

"EST"  / 

"EOT" 

;  Eastern:  -  5/  -  4 

/ 

"CST"  / 

"COT" 

;  Central:  -  6/  -  5 

/ 

"MST"  / 

"MOT" 

s  Mountain:  -  7/  -  8 

/ 

"PST"  / 

"POT" 

;  Pacific:  -  8/  -  7 

/ 

1ALPHA 

;  Military:  Z  »  UT; 

;  A:— 1;  (J  not  used) 

;  M:— 12;  Ns+1;  Y:+12 

/ 

(  <"+"  / 

"-")  4DIGIT  ) 

;  Local  differential 
;  hours+min.  (HHMM) 

5.2.  SEMANTICS 

If  included,  day-of-week  must  be  the  day  implied  by  the  date 
specification. 

Time  zone  may  be  indicated  in  several  ways.  "UT"  is  Univer¬ 
sal  Time  (formerly  called  "Greenwich  Mean  Time");  "GMT"  is  per¬ 
mitted  as  a  reference  to  Universal  Time.  The  military  standard 
uses  a  single  character  for  each  zone.  "Z"  is  Universal  Time. 
"A"  indicates  one  hour  earlier,  and  "M”  indicates  12  hours  ear¬ 
lier;  "N"  is  one  hour  later,  and  "Y"  is  12  hours  later.  The 
letter  "j"  is  not  used.  The  other  remaining  two  forms  are  taken 
from  ANSI  standard  X3. 51-1975.  One  allows  explicit  indication  of 
the  amount  of  offset  from  UT;  the  other  uses  common  3-character 
strings  for  indicating  time  zones  in  North  America. 
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«.  AOORESS  SPECIFICATION 


6.1.  SYNTAX 

Address 

m 

/ 

mailbox  ; 

group  ; 

named  list 

group 

m 

phrase  (#mailbox) 

mailbox 

m 

/ 

addr-spee  ; 

phrase  route-addr  ; 

simple  address 
name  A  addr-spec 

route-addr 

m 

"<"  (route]  addr-speo  •>" 

' 

route 

m 

l#("*a  domain)  at*  ■  ; 

path-relative 

addr-spec 

m 

local-part  domain  ; 

global  address 

local-part 

m 

word  word)  ; 

s 

s 

udlnterpreted 

case-preserved 

domain 

m 

sub-domain  sub-domain) 

sub-domain 

m 

domain-ref  /  domain-literal 

domain-ref 

m 

atom  ; 

symbolic  reference 

6.2.  SEMANTICS 

A  mailbox  receives  mail.  Zt  is  a  conceptual  entity  which 
does  not  necessarily  pertain  to  file  storage.  For  example,  some 
sites  may  choose  to  print  mail  on  their  line  printer  and  deliver 
the  output  to  the  addressee's  desk. 

A  mailbox  specification  comprises  a  person,  system  or  pro¬ 
cess  name  reference,  a  domain-dependent  string,  and  a  name-domain 
reference.  The  name  reference  is  optional  and  is  usually  used  to 
indicate  the  human  name  of  a  recipient.  The  name-domain  refer¬ 
ence  specifies  a  sequence  of  sub-domains.  The  domain-dependent 
string  is  uninterpreted,  except  by  the  final  sub-domain;  the  rest 
of  the  mail  service  merely  transmits  it  as  a  literal  string. 

6.2. 1.  DOMAINS 

A  name-domain  is  a  set  of  registered  (mal  names.  A  name- 
domain  specification  resolves  to  a  su\v  linate  name-domain 
specification  or  to  a  terminal  domain  impendent  string. 
Kenct,  domain  specification  is  extensible,  permitting  any 
nuirbe"  of  registration  levels. 
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Name-domains  modal  a  global,  logical,  hierarchical  addressing 
scheme.  Tha  model  is  logical,  in  that  an  address  specifica¬ 
tion  is  related  to  name  registration  and  is  not  necessarily 
tied  to  transmission  path.  The  model's  hierarchy  is  a 
directed  graph,  called  an  in-tree,  such  that  there  is  a  single 
path  from  the  root  of  the  tree  to  any  node  in  the  hierarchy, 
if  more  than  one  path  actually  exists,  they  are  considered  to 
be  different,  addressee. 

The  root  node  is  common  to  all  addresses;  consequently,  it  is 
not  referenced.  Its  children  constitute  "top-level”  name- 
domains.  usually,  a  service  has  access  to  its  own  full  domain 
specification  and  to  the  names  of  all  top-level  name-domains. 

The  "top”  of  the  domain  addressing  hierarchy  —  a  child  of  the 
root  —  is  indicated  by  the  right-most  field,  in  a  domain 
specification,  its  child  is  specified  to  the  left,  its  child 
to  the  left,  and  so  on. 

Some  groups  provide  formal  registration  services;  these  con¬ 
stitute  name-domains  that  are  independent  logically  of 
specific  machines.  In  addition,  networks  and  machines  impli¬ 
citly  composo  name— aomains,  since  their  member ship  usually  Li 
registered  in  name  tables. 

in  the  case  of  formal  registration,  an  organization  implements 
a  (distributed)  data  base  which  provides  an  address-to-route 
mapping  service  for  addresses  of  the  form: 

per sondregistry. organization 

Note  that  "organization"  is  a  logical  entity,  separate  from 
any  particular  communication  network. 

A  mechanism  for  accessing  "organization”  is  universally  avail¬ 
able.  That  mechanism,  in  turn,  seeks  an  instantiation  of  the 
registry;  its  location  is  not  indicated  in  the  address  specif¬ 
ication.  it  is  assumed  that  the  system  which  operates  under 
the  name  "organization”  knows  how  to  find  a  subordinate  regis¬ 
try.  The  registry  will  then  use  the  "person"  string  to  deter¬ 
mine  where  to  send  the  mail  specification. 

The  latter,  network-oriented  case  permits  simole,  direct, 
attachment-related  address  specification,  such  as: 

userOhost . network 

Once  the  network  is  accessed,  it  is  expected  that  a  message 
will  go  directly  to  the  host  and  that  the  host  will  resolve 
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tha  user  name,  placing  tha  aaaaaga  in  the  user’s  mailbox. 

«.?. 2.  ABBREVIATED  DOMAIN  SPECIFICATION 

Sinca  any  number  of  lavala  ia  poaaibla  within  tha  doaain 
hierarchy,  apacif ication  of  a  fully  qualified  addraaa  can 
hccome  inconvenient.  This  standard  peraits  abbreviated  domain 
specification,  in  a  special  case: 

For  tha  address  of  the  sender,  call  the  left-most 
sub-domain  Level  N.  in  a  header  address,  if  all  of 
the  sub-domains  above  (i.e.,  to  the  right  of)  Level  n 
are  the  same  as  those  of  the  sender,  then  they  do  not, 
have  to  appear  in  the  specification.  otherwise,  the 
address  must  be  fully  qualified. 

This  feature  is  subject  to  approval  by  local  sub- 
domains.  Individual  sub-domains  may  require  their 
member  systems,  which  originate  mail,  to  provide  full 
domain  specification  only.  When  permitted,  abbrevia¬ 
tions  may  be  present  only  while  the  message  stays 
within  the  sub-domain  of  the  sender. 


use  of  this  mechr.nism  requires  tne  sender's  sub-domain 
to  reserve  the  names  of  all  top-level  domains,  so  that 
full  specifications  can  be  distinguished  from  abbrevi¬ 
ated  specifications. 

For  example,  if  a  sender’s  address  is: 

sendereregistry-A.reiistry-l.organizc>tion-X 


and  cne  recipient's  address  is: 

recipientOregistry-B.registry-1 .orga.ilzation-X 
and  another's  is: 

r ecipientOreg is try-C.  regtstry-2. organ ization-X 

then  registry-1 .organizatiou-X"  rssd  not  be  specified  in  the 
the  message,  but  "registry-nS. registry-2"  DOES  have  to  be 
specified.  That  is,  the  first  two  addresses  may  be  abbrevi¬ 
ated.  but  the  third  address  m^jst  be  fully  specified. 

when  a  message  crosses  a  domain  boundary,  all  addresses  must 
be  specified  in  the  full  format,  ending  with  the  top-level 
name-domain  in  the  right-most  field.  It  is  the  responsibility 
of  mail  forwarding  services  to  ensure  that  addresses  conform 


August  13.  1982 


RFC  #822 


107 


Standard  for  ARPA  Znternat  Text  Messages 


with  this  requirement.  Zn  the  case  of  abbreviated  addresses, 
the  relaying  service  must  make  the  necessary  expansions.  Zt 

should  be  noted  that  it  often  is  difficult  for  such  a  service 

to  locate  all  occurrences  of  address  abbreviations.  For  exam¬ 
ple,  it  will  not  be  possible  to  find  such  abbreviations  within 
the  body  of  the  message.  The  'Return-Path*  field  can  aid 
recipients  in  recovering  from  these  errors. 

Note:  When  passing  any  portion  of  an  addr-spec  onto  a  process 
which  does  not  interpret  data  according  to  this  stan¬ 
dard  (e.g.,  mail  protocol  servers).  There  must  be  NO 

LWSP-chars  preceding  or  following  the  at-sign  or  any 

delimiting  period  such  as  shown  in  the  above 

examples,  and  only  ONE  SPACE  between  contiguous 
<word>s. 

6.2.3.  DOMAIN  TERMS 

A  domain-ref  must  be  THE  official  name  of  a  registry,  network, 
or  host.  Zt  is  a  symbolic  reference,  within  a  name  sub- 
domain.  At  times,  it  is  necessary  to  bypass  standard  mechan¬ 
isms  for  resolving  such  references,  using  more  primitive 
information,  such  as  a  network  host  address  rather  than  its 
associated  host  name. 

To  permit  such  references,  this  standard  provides  the  domain- 
literal  construct.  Its  contents  must  conform  with  the  needs 
of  the  sub-domain  in  which  it  is  interpreted. 

Domain-literals  which  refer  to  domains  within  the  ARPA  Inter¬ 
net  specify  32-bit  Internet  addresses,  in  four  8-bit  fields 
noted  in  decimal,  as  described  in  Request  for  Comments  #820. 
"Assigned  Numbers."  For  example: 

{10.0.3.19] 

Note:  THE  USE  OF  DOMAIN-LITERALS  IS  STRONGLY  DISCOURAGED.  It 

is  permitted  only  as  a  means  of  bypassing  temporary 
system  limitations,  such  as  name  tables  which  are  not 
complete. 

The  names  of  "top-level"  domains,  and  the  names  of  domains 
under  in  the  ARPA  Internet,  are  registered  with  the  Network 
Information  Center,  SRI  International,  Menlo  Park,  California. 

6.2.4.  DOMAIN-DEPENDENT  LOCAL  STRING 

The  local-part  of  an  addr-spec  in  a  mailbox  specification 
(i.e.,  the  host's  name  for  the  mailbox)  is  understood  to  be 
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whatever  the  receiving  nail  protocol  server  allows.  For  exam¬ 
ple.  some  systems  do  not  understand  mailbox  references  of  the 
form  "P,  0.  Q.  Bach",  but  others  do. 

This  specification  treats  periods  (".")  as  lexical  separators. 
Hence,  their  presence  in  local-parts  which  are  not  quoted- 
strings,  is  detected.  However,  such  occurrences  carry  no 
semantics.  That  is,  if  a  local-part  has  periods  within  it.  an 
address  parser  will  divide  the  local-part  into  several  tokens, 
but  the  sequence  of  tokens  will  be  treated  as  one  un inter¬ 
preted  unit.  The  sequence  will  be  re-assembled,  when  the 
actress  is  passed  outside  of  the  system  such  as  to  a  mail  pro¬ 
tocol  service. 

For  example,  the  address: 

First.LastBRegistry.org 

is  legal  and  does  not  require  the  local-part  to  be  surrounded 
with  quotation-marks.  (However,  "First  Last"  DOES  require 
quoting.)  The  local-part  of  the  address,  when  passed  outside 
of  the  mail  system,  within  the  Registry. Org  domain,  is 
"First. Last",  again  without  quotation  marks. 

6.2.5.  BALANCING  LOCAL-PART  AND  DOMAIN 

In  some  cases,  the  boundary  between  local-part  and  domain  can 
be  flexible.  The  local-part  may  be  a  simple  string,  which  is 
used  for  the  final  determination  of  the  recipient's  mailbox. 
All  other  levels  of  reference  are,  therefore,  part  of  the 
domain . 

For  some  systems,  in  the  case  of  abbreviated  reference  to  the 
local  and  subordinate  sub-domains,  it  may  be  possible  to 
specify  only  one  reference  within  the  domain  part  and  place 
the  other,  subordinate  name-domain  references  within  the 
local-part.  This  would  appear  as: 

mailbox. subl . sub20this-domain 

Such  a  specification  would  be  acceptable  to  address  parsers 
which  conform  to  RFC  #733,  but  do  not  support  this  newer 
Internet  standard.  While  contrary  to  the  intent  of  this  stan¬ 
dard,  the  form  is  legal. 

Also,  some  sub-domains  have  a  specification  syntax  which  does 
not  conform  to  this  standard.  For  example: 

sub-net .mailboxOsub-domain. domain 
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uses  a  different  parsing  sequence  for  local-part  than  for 
domain. 

Note:  As  a  rule,  the  domain  specification  should  contain 
fields  which  are  encoded  according  to  the  syntax  of 
this  standard  and  which  contain  generally-standardized 
information.  The  local-part  specification  should  con¬ 
tain  only  that  portion  of  the  address  which  deviates 
from  the  form  or  intention  of  the  domain  field. 

6.2.6.  MULTIPLE  MAILBOXES 

An  individual  may  have  several  mailboxes  and  wish  to  receive 
mail  at  whatever  mailbox  is  convenient  for  the  sender  to 
access.  This  standard  does  not  provide  a  means  of  specifying 
"any  member  of"  a  list  of  mailboxes. 

A  set  of  individuals  may  wish  to  receive  mail  as  a  single  unit 
(i.e.,  a  distribution  list).  The  <group>  construct  permits 
specification  of  such  a  list.  Recipient  mailboxes  are  speci¬ 
fied  within  the  bracketed  part  A  copy  of  the 

transmitted  message  is  to  be  sent  to  each  mailbox  listed. 
This  standard  does  not  permit  recursive  specification  of 
groups  within  groups. 

While  a  list  must  be  named,  it  is  not  required  that  the  con¬ 
tents  of  the  list  be  included.  In  this  case,  the  <address> 
serves  only  as  an  indication  of  group  distribution  and  would 
appear  in  the  form: 

name : ; 

Some  mail  services  may  provide  a  group-list  distribution 
facility,  accepting  a  single  mailbox  reference,  expanding  it 
to  the  full  distribution  list,  and  relaying  the  mail  to  the 
list's  members.  This  standard  provides  no  additional  syntax 
for  indicating  such  a  service.  Using  the  <group>  address 
alternative,  while  listing  one  mailbox  in  it,  can  mean  either 
that  the  mailbox  reference  will  be  expanded  to  a  list  or  that 
there  is  a  group  with  one  member. 

6.2.7.  EXPLICIT  PATH  SPECIFICATION 

At  times,  a  message  originator  may  wish  to  indicate  the 
transmission  path  that  a  message  should  follow.  This  is 
called  source  routing.  The  normal  addressing  scheme,  used  in 
an  addr-spec,  is  carefully  separated  from  such  information; 
the  <route>  portion  of  a  route-addr  is  provided  for  such  occa¬ 
sions.  it  specifies  the  sequence  of  hosts  and/or  transmission 
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services  that  are  to  be  traversed.  Both  domain-refs  and 
domain-literals  may  be  used. 

Note:  The  use  of  source  routing  is  discouraged.  Unless  the 
sender  has  special  need  of  path  restriction,  the  choice 
of  transmission  route  should  be  left  to  the  mail  tran¬ 
sport  service. 

6.3.  RESERVED  ADDRESS 

It  often  is  necessary  to  send  mail  to  a  site,  without  know¬ 
ing  any  of  its  valid  addresses.  For  example,  there  may  be  mail 
system  dysfunctions,  or  a  user  may  wish  to  find  out  a  person's 
correct  address,  at  that  aite. 

This  standard  specifies  a  single,  reserved  mailbox  address 
(local-part)  which  is  to  be  valid  at  each  site.  Mail  rent  to 
that  address  is  to  be  routed  to  a  person  responsible  for  the 
site's  mail  system  or  to  a  person  with  responsibility  for  general 
site  operation.  The  name  of  the  reserved  local-part  address  is: 

Postmaster 

so  that  "Postmasterddomain"  is  required  to  be  valiu. 

Note:  This  reserved  local-part  must  be  matched  without  sensi¬ 
tivity  to  alphabetic  case,  so  that  "postmaster",  "postmas¬ 
ter",  and  even  "poStmASteR"  is  to  be  accepted. 


August  13,  1982 


-  33  - 


RFC  #822 


111 


Standard  for  arpa  in tar not  Taxt  Maaaagaa 


7.  BIBLIOGRAPHY 


ANSI.  "USA  Standard  Code  for  Information  Interchange,”  X3.4. 
American  National  Standards  Institute:  New  York  (1908).  Also 
in:  Feinler,  E.  and  J.  Postel,  eds.,  "ARPANET  Protocol  Hand¬ 
book”,  NIC  7104. 

ANSI.  "Representations  of  Universal  Time,  Local  Time  Differen¬ 
tials,  and  United  States  Time  Zone  References  for  Information 
Interchange.”  X3. 51-1975.  American  National  Standards  Insti¬ 
tute:  New  York  (1975). 

Berner,  R.W.,  "Time  and  the  Computer."  In:  Interface  Age  (Peb. 
1979). 

Bennett.  C.J.  " JNT  Mall  Protocol”.  Joint  Network  Team,  Ruther¬ 
ford  and  Appleton  Laboratory:  Didcot,  England.  "v. 

Bhushan,  A.K.,  Pogran,  K.T.,  Tomlinson,  R.S.,  and  White,  J.E. 
"Standardizing  Network  Mail  Headers,”  ARPANET  Request  for 
Comments  No.  561,  Network  Information  Center  No.  13516;  SRI 
international:  Menlo  Park  (September  1973). 

Birrell,  A.D.,  Levin,  R.,  Needham,  R.M.,  and  Schroeder,  M.D. 
’Grapevine:  An  Exercise  in  Distributed  Computing.”  Communica¬ 
tions  Of  the  ACM  25,  4  (April  1982),  260-274. 

Crocker,  D.H.,  vittal,  J.J.,  Pogran,  K.T.,  Henderson,  D.A. 
"Standard  for  the  Format  of  ARPA  Network  Text  Message," 
ARPANET  Request  for  Comments  No.  733,  Network  Information 
Center  No.  41952.  SPI  International:  M6nlo  Park  (November 
1977). 

Feinler,  E.J.  and  Postel,  J.B.  ARPANET  Protocol  Handbook,  Net¬ 
work  Information  Center  No.  7104  (NTIS  AO  A003890) .  SRI 
International :  Menlo  Park  (April  1976). 

Harary,  F.  "Graph  Theory”.  Addison-wesley :  Reading,  Mass. 

(1963). 

Levin,  R.  and  Schroeder,  M.  "Transport  of  Electronic  Messages 
through  a  Network,"  Teleinformatics  79,  p 29-33.  North 
Holland  (1979).  Also  as  Xerox  Palo  Alto  v_y earch  Center 
Technical  Report  CSL-79-4. 

Myer,  T.H.  and  Henderson,  D.A.  "Message  Transmission  Protocol," 
ARPANET  Request  for  Comments,  No.  6B0,  Network  Information 
Center  No.  32116.-  SRI  International:  Menlo  Park  (1975). 


August  13,  1982 


34 


RFC  #822 


Standard  for  ARPA  Internet  Text  Message* 


MBS.  "Specification  of  Message  Format  for  Computer  Based  Message 
Systems,  Recommended  Federal  Information  Processing  Standard.” 
National  Bureau  of  Standards:  Gaithersburg,  Maryland 

(October  1981). 

NIC.  Internet  Protocol  Transition  workbook.  Network  information 
Center,  SRl-International,  Menlo  Park,  California  (March 
1982). 

Oppen,  O.C.  and  Oalal,  Y.K.  "The  Clearinghouse:  A  Decentralized 
Agent  for  Locating  Named  Objects  in  a  Distributed  Environ¬ 
ment,”  0PD-T8103.  Xerox  Office  Products  Division:  Palo  Alto, 
CA.  (October  1981) . 

Postal,  J.B.  "Assigned  Numbers,"  ARPANET  Request  for  Comments, 
No.  820.  SRI  International:  Menlo  Park  (August  1982). 

Postal,  J.3.  "Simple  Mail  Transfer  Protocol,"  ARPANET  Request 
for  Comments,  No.  821.  SRI  International:  Menlo  Park  (August 
1982). 

Shoch,  J.F.  "Internetwork  naming,  addreesing  and  routing,”  in 
Proc.  17th  IEEE  Computer  Society  International  Conference,  pp. 
72-79.  Sept.  1978,  IEEE  Cat.  No.  78  CH  1388-8C. 

Su,  Z.  and  Postal,  J.  "The  Domain  Naming  Convention  for  Internet 
User  Applications,”  ARPANET  Request  for  Comments,  No.  819. 
SRI  International:  Menlo  Park  (August  1982). 


August  13,  1982 


35 


RFC  #822 


Standard  for  ARPA  Internet  Taxt  Massages 


APPENDIX 


A.  EXAMPLES 

A. 1 .  ADDRESSES 

A, 1.1.  Alfred  Neuman  <NeumanOBBN-TENEXA> 

A. 1.2.  NeumanOBBN— TENEXA 

These  two  "Alfred  Neuman"  examples  have  identical  seman¬ 
tics,  as  far  as  the  operation  of  the  local  host's  mail  sending 
(distribution)  program  (also  sometimes  called  its  "mailer") 
and  the  remote  host's  mail  protocol  server  are  concerned.  In 
the  first  example,  the  "Alfred  Neuman”  is  ignored  by  the 
mailer,  as  "NeumanOBBN— TENEXA"  completely  specifies  the  reci¬ 
pient.  The  second  example  contains  no  superfluous  informa¬ 
tion,  and.  again,  "NeumanOBBN— TENEXA"  is  the  intended  reci¬ 
pient. 

Noto:  when  the  message  crosses  name-domain  boundaries,  then 
these  specifications  must  be  changed,  so  as  to  indicate 
the  remainder  of  the  hierarchy,  starting  with  the  top 
level. 

A. 1.3.  "Qeorge,  Ted"  <SharedOOroup. Arpanet> 

This  form  might  be  used  to  indicate  that  a  single  mailbox 
is  shared  by  several  users.  The  quoted  string  is  ignored  by 
the  originating  host's  mailer,  because  "SharedOQroup. Arpanet” 
completely  specifies  the  destination  mailbox. 

A. 1.4.  wilt  .  (the  Stilt)  ChamberlainONBA.us 

The  "(the  Stilt)"  is  a  cuiament  which  is  NOT  included  in 
the  destination  mailbox  address  handed  to  the  originating 
system's  mailer.  The  local-part  of  the  address  is  the  string 
"Wilt. Chamber  lain”,  with  NO  space  between  the  first  and  second 
words. 

A. 1.5.  Address  Lists 

Gourmets:  Pompous  Person  <WhoZiWhatZit*Cordon-Bleu>, 

Childs9WG3H. Boston,  Galloping  Gourmet® 

ANT. Down-Under  (Australian  National  Television), 
Cheapie®Discount-Liquors; , 

Cruisers:  PortSPortugal,  Jones®SEA; , 

AnotherOSomewhere. SomeOrg 
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This  group  list  exaaple  points  out  the  use  of  comments  and  the 
mixing  of  addresses  and  groups. 

A. 2.  ORIGINATOR  ITEMS 

A. 2.1.  Author-sent 

George  Jones  logs  into  his  host  as  "Jones".  He  sends 
mail  himself. 

From:  JonBsOGroup.Org 

or 


From:  George  Jones  <JonesOGroup.Org> 

A. 2. 2.  Secretary-sent 

George  Jones  logs  in  as  Jones  on  his  host.  His  secre¬ 
tary,  who  logs  in  as  Secy  sends  mail  for  him.  Replies  to  the 
mail  should  go  to  George. 

From:  George  Jones  <JonesOGroup> 

Sender:  SecyOOther-Group 

A. 2. 3.  Secretary-sent,  for  user  of  shared  directory 

George  Jones'  secretary  sends  mail  for  George.  Replies 
should  go  to  George. 

From:  George  Jones<SharedeGroup.Org> 

Sender:  SecyOOther-Group 

Note  that  there  need  not  be  a  space  between  "Jones”  and  the 
but  adding  a  space  enhances  readability  (as  is  the  case 
in  other  examples. 

A. 2. 4.  Committee  activity,  with  one  author 

George  is  a  member  of  a  committee.  He  wishes  to  have  any 
replies  to  his  message  go  to  all  committee  members. 

From:  George  Jones  <Jones©Host . Net> 

Sender:  JonesOHost 

Reply-To:  The  Committee:  JonesOHost . Net, 

SmithOOther.org, 

DoeOSomewhere-Else; 

Note  that  if  George  had  not  included  himself  in  the 
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enumeration  of  The  Committee,  he  would  not  have  gotten  an 
implicit  reply;  the  presence  of  the  "Reply-to"  field  SUPER¬ 
SEDES  the  sending  of  a  reply  to  the  person  named  in  the  "From” 
field. 


A. 2. 5.  Secretary  acting  as  full  agent  of  author 

George  Jones  asks  his  secretary  (SecyOHost)  to  send  a 
message  for  him  in  his  capacity  as  Group.  He  wants  his  secre¬ 
tary  to  h&ndle  all  replies. 

From:  George  Jones  <GroupOHost> 

Sender:  SecyOHost 

Reply-To:  SecyOHost 

A. 2.0.  Agent  for  user  without  online  mailbox 

A  friend  of  George's,  Sarah,  is  visiting.  George's 
secretary  sends  some  mail  to  a  friend  of  Sarah  in  computer- 
land.  Replies  should  go  to  George,  whose  mailbox  is  Jones  at 
Registry. 

From:  Sarah  Friendly  <SecyORegistry> 

Sender:  Secy-Name  <SecyORegistry> 

Reply-To:  JonesORegistry . 

A. 2. 7.  Agent  for  member  of  a  committee 

George's  secretary  sends  out  a  message  which  was  authored 
jointly  by  all  the  members  of  a  committee.  Note  that  the  name 
of  the  committee  cannot  be  specified,  since  <group>  names  are 
not  permitted  in  the  From  field. 

From:  JonesOHost, 

SmithOOther-Host, 

DoeaSomewher e-E 1 se 
Sender:  SecyOSHost 
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A. 3.  COMPLETE  HEADERS 
A. 3.1.  Minimum  raquirad 

Data:  26  Aug  76  1429  EOT  Data:  26  Aug  76  1429  EOT 

From:  JonesORegiatry .Org  or  From:  JonaaORagiatry.Org 

Beo:  To:  SmithBRegistry .Org 

Nota  that  the  "See"  field  may  ba  ampty,  while  tha  "To”  fiald 
ia  raquirad  to  hava  at  least  ona  addraaa. 

A. 3. 2.  uaing  aoma  of  the  additional  fielda 

Data:  26  Aug  76  1430  EDT 

From:  George  Jonea<GroupOHout> 

Sender :  SecyOSHOST 

To:  ”A1  aeuman”OMad-Host, 

Sam. ZrvingOOther-Hoat 
Meaaage-IO:  <aome. atr ingOSHOST> 

A. 3. 3.  About  aa  complex  aa  you're  going  to  get 

Data  :  27  Aug  76  0932  POT 

From  :  Kan  Oavla  <KOaviaOThla-Hoat.Thia-net> 

Subject  :  Re:  The  Syntax  in  the  RFC 

Sender  :  KSecyOOther-Hoat 

Reply-To  :  Sam. IrvingOReg. Organization 

To  :  George  Jones  <Group0Some-Reg. An-Org>, 

A1 . NeumanOMAO. Publisher 
cc  :  Important  folk: 

Tom  Softwood  <BalsaOTree.Root>. 

"Sam  lrving"OOthei — Host;, 

Standard  Distribution: 

/main/davis/people/standard60ther-Host, 

"< Jones>standar d . dist . 3"6Topa-20-Hoat>; 

Comment  Sam  is  away  on  business.  He  asked  me  to  handle 
his  mall  for  him.  He'll  be  able  to  provide  a 
more  accurate  explanation  whan  he  returns 
next  week. 

In-Reply-To:  <some. str ingODBM. Group>,  George's  message 
X-Special-action :  This  is  a  sample  of  uoei — defined  field- 

names.  There  could  also  be  a  field-name 
"Special-action",  but  its  name  might  later  be 
preempted 

Message-ID:  <4231 . 829 . XYxi-RhatOOther-Ho(*t> 
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8.  SIMPLE  FIELD  PARSING 

Soma  mail-reading  software  aystema  may  wish  to  perform  only 
minimal  processing,  ignoring  the  internal  ayntax  of  structured 
field-bodiea  and  treating  them  tha  aama  aa  unstructured-f ield- 
bodiaa.  Such  aoftwara  will  need  only  to  diatinguiah: 

o  Header  fialda  from  tha  massage  body. 

o  Beginninga  of  fialda  from  linea  which  continue  fialda, 

o  Field-namea  from  f ield-contenta. 

abbreviated  aat  of  ayntactic  rulea  which  followa  will 
auffice  for  thia  purpoaa.  It  daaeribaa  a  limited  view  of  aes- 
aagea  and  ia  a  aubaat  of  tha  ayntactic  rulea  provided  in  the  main 
part  of  thia  apecif ication.  One  email  exception  ia  that  the  con- 
tenta  of  field-bodiea  conaiat  only  of  text: 

B.l.  SYNTAX 


message 

field 

field-name 

field-body 


B.2.  SEMANTICS 

Headers  occur  before  the  message  body  and  are  terminated  by 
a  null  line  (i.e.,  two  contiguous  CRLFs). 

A  line  which  continues  a  header  field  begins  with  a  SPACE  or 
HTAB  character,  while  a  line  beginning  a  field  starts  with  a 
printaole  character  which  is  not  a  colon. 

A  field-name  consists  of  one  or  more  printable  characters 
(excluding  colon,  space,  and  control-characters).  A  field-name 
MUST  be  contained  on  one  line.  Upper  and  lower  case  are  not  dis¬ 
tinguished  when  comparing  field-names. 
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C.  DIFFERENCES  FROM  RFC  #733 

The  following  summarize*  the  differences  between  this  stan¬ 
dard  and  the  one  specified  in  Arpanet  Request  for  Comments  #733, 
"Standard  for  the  Format  of  ARPA  Network  Text  Messages".  The 
differences  are  listed  in  the  order  of  their  occurrence  in  the 
current  specification. 

C.l.  FXELO  DEFINITIONS 

C.1.1.  FIELD  NAMES 

These  now  must  be  a  sequence  of  printable  characters.  They 
may  not  contain  any  LWSP-chars. 

C.2.  LEXICAL  TOKENS 

C.2.1.  SPECIALS 

The  characters  period  (*."),  left-square  bracket  ("t"),  and 
right-square  bracket  ("]")  have  been  added.  For  presentation 
purposes,  and  when  passing  a  specification  to  a  system  that 
does  not  conform  to  this  standard,  periods  are  to  be  contigu¬ 
ous  with  their  surrounding  lexical  tokens.  No  lineai — white- 
space  is  .  permitted  between  them.  The  presence  of  one  LWSP- 
char  between  other  tokens  is  still  directed. 

C.2.2.  ATOM 

Atoms  may  not  contain  SPACE. 

C.2.3.  SPECIAL  TEXT 

ctext  and  qtext  nave  had  backslash.  ("\")  added  to  the  list  of 
prohibited  characters. 

C. 2.4.  DOMAINS 

The  lexical  tokens  <domain-literal>  and  <dtext>  have  been 
added. 

C.3.  MESSAGE  SPECIFICATION 
C.3.J.  TRACE 

The  "Return-path:"  and  "Received:"  fields  have  been  specified. 
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C.3.2.  PROM 

The  "Prom*  field  must  contain  machine-usable  addresses  (addr- 
spec) .  Multiple  addresses  may  be  specified,  but  named-lists 
(groups)  may  not. 

C.3.3.  RESENT 

The  meta-construct  of  prefacing  field  names  with  the  string 
"Resent-”  has  been  added,  to  indicate  that  a  message  has  been 
forwarded  by  an  intermediate  recipient. 

C.3.4.  DESTINATION 

A  message  must  contain  at  least  one  destination  address  field. 
”To"  and  "CC"  are  required  to  contain  at  least  one  address. 

C.3.5.  IN— REPLY— TO 

The  field-body  is  no  longer  a  comma-separated  list,  although  a 
sequence  is  still  permitted. 

C.3.6.  REFERENCE 

The  field-body  is  no  longer  a  comma-separated  list,  although  & 
sequence  is  still  permitted. 

C.3.7.  ENCRYPTED 

A  field  has  been  specified  that  permits  senders  to  indicate 
that  the  bod^  of  a  message  has  been  encrypted. 

C.3.8.  EXTENSION-FIELD 

Extension  fields  are  prohibited  from  beginning  with  the  chai — 
acters  "X-". 

C.4.  DATE  AND  TIME  SPECIFICATION 
C.4.1.  SIMPLIFICATION 

Fewer  optional  forms  are  permitted  and  the  list  of  three- 
letter  timo  zones  has  been  shortened. 

C.5.  ADDRESS  SPECIFICATION 
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C.5.1.  ADDRESS 

The  use  of  quoted-string,  and  the  ”:”-atom-":"  construct,  have 
been  removed.  An  address  now  is  either  a  single  mailbox 
reference  or  is  a  named  list  of  addresses.  The  latter  indi¬ 
cates  a  group  distribution. 

C.S.2.  GROUPS 

Group  lists  are  now  required  to  to  have  a  name.  Group  lists 
may  not  be  nested. 

C.5.3.  MAILBOX 

A  mailbox  specification  may  indicate  a  person's  name,  as 
before.  Such  a  named  lict  no  longer  may  specify  multiple 
mailboxes  and  may  not  be  nested. 

C.S.4.  ROUTE  ADDRESSING 

Addresses  now  are  taken  to  be  absolute,  global  specifications, 
independent  of  transmission  paths.  The  <route>  construct  has 
been  provided,  to  permit  explicit  specification  of  transmis¬ 
sion  path.  RFC  #733 's  use  of  multiple  at-signs  ("0")  was 
intended  as  a  general  syntax  for  indicating  routing  and/or 
hierarchical  addressing.  The  current  standard  separates  these 
specifications  and  only  one  at-sign  is  permitted. 

C.5.5.  AT— SIGN 

The  string  "  at  *  no  longer  is  used  as  an  address  delimiter. 
Only  at-sign  ("©")  serves  the  function. 

C.5.6.  DOMAINS 

Hierarchical ,  logical  name-domains  have  been  added. 

C.6.  RESERVED  ADDRESS 

The  local-part  ’•Postmaster"  has  been  reserved,  so  that  users  can 
be  guaranteed  at  !east  one  valid  address  at  a  site. 
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0.  ALPHABETICAL  LISTING  OF  SYNTAX  RULES 

address 

mailbox 

one  addressee 

/ 

group 

i 

named  list 

addr-spec 

ae 

local-part  "•"  domain 

global  address 

ALPHA 

■B 

<any  ASCII  alphabetic  character> 

i 

(101-132,  65.-  90.) 

(141-172,  97.-122.) 

atom 

Ml 

l*<any  CHAR  except  specials,  SPACE  and  CTLs> 

authentic 

Ml 

"From"  " 

"  mailbox 

Single  author 

/ 

(  "Sender*  • 

"  mailbox 

Actual  submittor 

"From" 

"  l#mailbox) 

Multiple  authors 

or  not  sender 

CHAR 

m 

<any  ASCII  character> 

(  0-177,  0.-127.) 

comment 

m 

"("  • (ctext  /  quoted-pair  /  comment)  ")" 

CR 

m 

<ASCI I  CR,  carriage  return> 

(  15,  13.) 

CRLF 

m 

CR  LF 

ctext 

m 

<any  CHAR  excluding  "(", 

»  may  be  folded 

")",  "\"  S  CR, 

t  including 

linear-white-space> 

CTL 

m 

<any  ASCII  control 

(  0-  37.  0.-  31.) 

character  and  DEL> 

(  177,  127.) 

date 

m 

1*2DIQIT  month  2DIGIT 

day  month  year 

e.g.  20  Jun  82 

dates 

m 

orig-date 

Original 

[  resent-date  1 

Forwarded 

date-time 

m 

[  day  ","  1  date  time 

dd  mm  yy 

hh:mm:ss  zzz 

day 

m 

"Mon"  /  "Tue" 

f  "wed"  /  "Thu" 

/ 

"Fri"  /  "Sat" 

f  "Sun" 

delimiters 

m 

specials  /  linear-wnite-space 

/  comment 

destination 

sc, 

"To" 

"  l#address 

Primary 

/ 

"Resent-To"  " 

”  l#address 

/ 

"cc"  " 

"  '^address 

Secondary 

/ 

"Resent-cc"  " 

"  l#address 

/ 

"bcc"  " 

”  #address 

Blind  carbon 

/ 

"Resent-bcc"  " 

”  ^address 

DIGIT 

m 

<any  ASCII  decimal  digit> 

(  60-  71,  48.-  57.) 

domain 

m 

sub-domain  •(". 

sub-domain) 

domain-literal 

■  "["  • (dtext 

t  quoted-pair) 

"  J  •* 

domain-ref 

m 

atom 

symbolic  reference 

dtext  *  <any  CHAR  excluding  "[",  ;  ■>  may  be  folded 

"\"  &  CR,  &  including 
1 inear-wh i te-space> 
extension-field  - 

<Any  field  which  is  defined  in  a  document 
published  as  a  formal  extension  to  this 
specification;  none  will  have  names  beginning 
with  the  string  "X-"> 
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field-body  ■ 


field  -  field-name  [  field-body  ]  CRLF 

fields  -  dates  ;  Creation  time, 

source  ;  author  id  &  one 

i*destination  ;  address  required 

•optional-field  ;  others  optional 

field-body-contents 
[CRLF  LWSP-char  field-body] 
field-body-contents  - 

<the  ASCII  characters  making  up  the  field-body,  as 
defined  in  the  following  sections,  and  consisting 
of  combinations  of  atom,  quoted-string,  and 
specials  tokens,  or  else  consisting  of  texts> 
l*<any  CHAR,  excluding  CTLs,  SPACE,  and 


field-name 

group 

hour 

HTAB 

LF 


phrase 
20IQIT 

<ASCII  HT. 
<ASCII  LF, 


[#mailbox] 
2DIGIT  [":' 


2DIGIT ] 


hor izontal-tab> 
linefeed> 

linear-white-space  ■  1*([CRLF]  LWSP-char) 


local-part 

LWSP-char 

mailbox 

message 


month 


word  «(’ 


word) 


SPACE  /  HTAB 
addr-spec 
phrase  route-addr 
fields  •(  crlf  »text  ) 


s  « 

/ 

/ 


msg-id  * 

optional-field 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

orig-date  ** 
originator  = 


Jan" 

May" 

Sep' 


■Feb" 

•Jun" 

■Oct" 


00:00:00  -  23:59:59 
(  11.  9.) 


•Mar* 

■Jul" 

■Nov" 


■<"  addi — spec  ">’ 


(  12.  10. 
semantics  «  SPACE 
CRLF  »  folding 
uninterpreted 
case-preserved 
semantics  >  SPACE 
simple  address 
name  &  ador-spec 
Everything  after 
first  null  line 
is  message  body 
"Apr" 

"Aug" 

"Dec" 

;  Unique  message  id 


) 


phrase 


■Message-ID" 

" Resen t-Message-ID" 
"In-Reply-To" 
"References" 
"Keywords" 

"Subject" 

"Comments" 
"Encrypted" 
extension-field 
user-def ined-f ield 
"Oate"  ":" 

authentic 
[  "Reply-To" 
l*word 


msg-id 
msg-^d 

•(phrase  /  msg-id) 
•(phrase  /  msg-id) 
tfphrase 
•  text 
•text 
U’2word 

;  To  be  defined 
;  May  be  pre-empted 

date-tim^ 

authenticated  addr 


i#addross]  ) 


Sequence  of  words 
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qtext  <■ 

quoted-pair  « 
quoted-string 

received  - 


<any  CHAR  excepting  <">, 

"\*  l  CR,  and  including 
linear-white-space> 

"\"  CHAR 

*  <•>  •(qtext/quoted-pair)  <•> 

"Received"  “s"  . 

("from"  domain] 

("by"  domain] 

("via*  atom] 

•("with"  atom) 

("id"  msg-id] 

("for"  addr-spec] 
date-time 


■>  may  be .folded 


may  quote  any  char 
Regular  qtext  or 
quoted  chars, 
one  per  relay 
sending  host- 
receiving  host 
physical  path 
link/mail  protocol 
receiver  msg  id 
initial  form 
time  received 


resent  ■  resent-authentic 

(  " Resen t-Reply-To" 
resent-authentic  « 

■  "Resent-Prom" 

/  (  "Resent-Sender" 
"Resent-From" 


l#address]  ) 

mailbox 
mailbox 
l#mailbox  ) 


resent-date 

m 

"Resent-Date"  ":"  date-time 

return 

m 

"Return-path"  ":"  route-addr  ; 

route 

m 

1#("#"  domain)  ":*  ; 

route-addr 

m 

"<"  [route]  addr-spec  ">" 

source 

[  trace  ] 
originator 
(  resent  ] 

SPACE 

m 

cASCII  SP,  space> 

specials 

=* 

"("  /  ")"  /  "<"  /  ">"  /  "®” 

/ 

"."  /  ":"  /  ":"  /  ’\"  /  <"> 

/ 

"."  /  "["  /  "]" 

sub-domain 

* 

domain-ref  /  domain-literal 

text 

a 

<any  CHAR;  including  bare 

CR  &  bare  LF,  but  NOT 
including  CRLF> 

time 

hour  zone 

trace 

m 

return 

l*received 

usei — def ined-f ield 


return  address 
path-relative 

net  traversals 
original  mail 
forwarded 

(  40,  32.) 

Must  be  in  quoted- 
string,  to  use 
within  a  word. 

**>  atoms,  specials, 
comments  and 
quoted-st.rings  are 
NOT  recognized. 
ANSI  and  Military 
path  to  sender 
receipt  tags 


<Any  field  which  has  not  been  defined 
in  this  specification  or  published  as  an 
extension  to  this  specification;  names  for 
such  fields  must  be  unique  and  may  be 
pre-empted  by  published  extensions> 
word  ■  atom  /  quoted-string 
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"EST"  /  "EDT" 

"CST"  /  "COT" 

"MST"  /  "MOT" 

"PST"  /  "PDT* 
1ALPHA 

<ASCZZ  quota  mark> 


Universal  Tima 
North  American  :  UT 
Eastern:  -  6/  -  ♦ 

Central:  -  6/  -  5 

Mountain:  -  7/  -  6 

Pacific:  -  8/  -  7 

Military:  Z  -  UT; 

(  42.  34.) 


f 

I 

>V 


'p- 

l-i 

>1 

;,I 
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